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.  I.  INTRODUCTION 


Flight  simulation  has  been  an  important  computer  graphics  application, 
embracing  a  range  of  systems  from  a  $32.00  program  for  a  personal  computer 
[Ref.  1]  to  special  purpose  machines  costing  millions  of  dollars  [Ref.  2].  The 
capabilities  of  these  systems  are  spread  across  a  range  nearly  as  wide  as  their 
costs,  with  great  variances  in  speed  (frames  displayed  per  second),  realism, 
flexibility,  and  area  of  flight.  We  present  here  a  system  that  is  relatively 
inexpensive,  yet  still  fast  enough  to  present  a  real-time  three-dimensional  view  of 
digitized  terrain.  We  built  this  system  on  a  commercially  available,  high- 
performance  graphics  workstation,  the  Silicon  Graphics,  Incorporated  IRIS-2400 
Turbo.  The  IRIS  system  was  selected  because  of  its  local  availability  and  its 
performance  capabilities.  The  flight  simulator  presented  here  does  not  use  the 
natural  color  and  shape  of  individual  terrain  elements  (in  order  to  achieve  real¬ 
time  performance),  but  it  is  sufficiently  realistic  to  provide  the  feeling  of  flight 
and  allow  identification  of  the  displayed  terrain  and  targets. 

A.  FOG-M 

1.  Background 

The  project  presented  here  was  built  in  response  to  the  United  States 
Army  Combat  Developments  Experimentation  Center's  need  to  simulate  the 


1 


operation  of  the  Fiber^Optically  Guided  Missile  (FOG-M)  [Ref.  3],  but  this  missile 
is  also  being  considered  for  use  by  the  United  States  Marine  Corps  [Ref.  4]. 
Simulation  is  necessary  in  order  to  test  and  evaluate  the  tactics,  doctrine  and 
training  requirements  associated  with  the  missile  without  the  expense  and  danger 
of  actual  firings  during  simulated  combat  field  trials.  The  FOG-M  is  a  generic 
family  of  remotely-piloted,  video-guided  munitions,  but  for  the  purpose  of  this 
prototype  simulator,  the  weapons  are  all  logically  equivalent,  ■  ,he  entire 
family  is  referred  to  as  “the  missile.”  In  order  to  avoid  security  constraints,  the 
parameters  and  operational  characteristics  used  in  this  work  were  not  taken  from 
exact  FOG-M  specifications.  The  parameters  and  technical  specifications  are  all 
estimates,  based  on  reasonableness  and  consistency  with  general,  unclassified 
descriptions  of  the  FOG-M. 

2.  Description 

The  actual  FOG-M  missile  is  six  inches  in  diameter,  five  and  one-half  feet 
high,  weighs  eighty-three  pounds,  and  costs  about  $20,000  [Ref.  4].  It  has  a  video 
camera  mounted  in  its  nose,  which  transmits  a  black-and-white  picture  back  to 
the  operator’s  console  (which  consists  of  a  television  screen,  a  computer,  and  a 
joystick)  over  the  fiber-optic  link.  (The  simulator  display  offers  the  user  the  choice 
of  either  color  or  black-and-white;  color  is  the  default  for  the  simulator  despite  the 
operator  view  of  the  missile  being  black-and-white.  The  color  compensates  for 
some  of  the  loss  in  realism  and  identifiability  inherent  in  a  polygonal 


representation  of  natural  objects).  Before  launch,  in  normal  operation,  the  missile 
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is  given  a  general  direction  to  a  target  and  the  altitude  of  the  highest  point  within 
its  range.  The  simulator  allows  values  in  excess  of  FOG-M  operational 
capabilities  for  speed,  range,  and  altitude  above  ground  level  (AGL),  but  the 
default  values  of  two  hundred  knots,  ten  kilometers,  and  one  thousand  meters  are 
characteristic  of  this  type  of  missile.  As  soon  as  the  missile  is  in  position,  it  begins 
transmitting  video  images.  When  launched,  the  missile  rises  to  approximately 
two  hundred  feet  above  the  highest  terrain  point,  and  then  levels  off  in  horizontal 
flight  in  the  targeted  direction.  The  operator  controls  the  pan  and  tilt  angle  of 
the  camera  with  the  joystick,  and  can  dial  in  changes  to  the  heading  and  altitude 
of  the  missile.  The  operator  also  has  the  capability  to  zoom  the  camera’s  field  of 
view  from  eight  degrees  to  fifty-five  degrees,  and  to  designate  (“lock-on”  to)  a 
target  for  automatic  homing  by  the  missile. 

B.  ASPECTS  OF  FLIGHT  SIMULATION 

There  are  many  aspects  to  flight  simulation.  Modern  commercial  simulators 
provide  sophisticated  mock-ups  of  cockpits  and  controls  and  highly  detailed  out 
the  window  views.  By  mounting  the  simulator  on  a  moving  platform,  a  true  sense 
of  the  physical  feelings  of  acceleration  and  roil  can  be  achieved.  These  systems 
also  cost  millions  of  dollars. 

One  of  the  first  decisions  that  must  be  made  when  designing  a  flight  simulator 
is,  “For  what  purpose  will  the  simulator  be  used?”  The  answer  to  this  question 
drives  most  of  the  design  decisions  that  have  to  be  made.  Since  the  purpose  of 


this  project  is  to  provide  a  simulation  of  the  FOG-M  missile  as  viewed  from  its 
operator’s  console,  it  is  felt  that  the  most  important  items  to  model  are  the 
simulated  video  display  of  the  terrain  and  the  actual  operator  controls.  The 
terrain  should  appear  realistic  enough  that  its  major  features  are  recognizable  to  a 
person  familiar  with  the  area.  The  controls  should  allow  for  the  same 
functionality  as  the  actual  console.  The  simulator  must,  of  course,  also  provide  a 
feeling  that  the  missile  is  in  motion  over  the  terrain.  The  effectiveness  of  the 
feeling  of  motion  provided  by  a  flight  simulator  can  be  largely  measured  by  two 
criteria:  the  realism  of  the  displayed  scene  and  the  update  rate  of  the  display. 

1.  Realism 

Many  factors  contribute  to  the  perceived  realism  of  a  displayed  natural 
scene.  Early  attempts  to  quantitatively  measure  realism  consisted  of  counting  the 
number  of  “edges”  or  lines  that  a  scene  contained.  This  later  gave  way  to 
counting  the  number  of  “faces”  or  polygons  in  a  scene.  Since  each  polygon  was 
colored  in  a  single  shade,  it  was  felt  that  each  polygon  represented  a  single  “bit” 
of  information  in  the  scene.  Therefore,  the  more  polygons  the  scene  contained, 
the  more  “realistic”  it  was  felt  to  be  [Ref.  5:pp.  27-28). 

The  latest  advances  in  computer  graphics  have  also  made  this  measure  of 
effectiveness  obsolete.  With  the  introduction  of  systems  that  are  able  to  fill 
polygons  with  textured  patterns,  a  single  polygon  can  now  contain  thousands  of 
“bits”  of  information.  As  a  result,  a  scene  drawn  with  a  few  textured  polygons 
can  appear  more  realistic  than  one  with  an  order  of  magnitude  more  untextured 


ones.  Early  textures  consisted  of  superimposing  things  such  as  mathematical 
noise  functions  or  stripes  on  the  polygons.  More  recent  advances  have  allowed  the 
texture  to  be  derived  from  digital  photographs  of  a  similar  scene.  For  example, 
polygons  representing  a  part  of  terrain  covering  by  meadow  could  be  filled  with  a 
digital  texture  derived  from  an  aerial  photograph  of  a  meadow  [Ref.  5:  p.  28]. 

Since  most  currently  available  graphics  workstations  do  not  support  the 
use  of  texture  filled  polygons,  the  use  of  texture  was  deemed  to  be  outside  the 
scope  of  the  current  project.  Rather,  the  project’s  work  concentrated  on 
determining  how  realistically  a  scene  could  be  rendered  in  real-time  incorporating 
only  the  use  of  lighting  and  shading  models  along  with  terrain  hidden-surface 
algorithms.  These  topics  are  covered  in  more  detail  in  Chapter  V. 

2.  Frame  Update  Speed 

Another  important  aspect  of  a  flight  simulator’s  performance  is  the  speed 
at  which  it  is  capable  of  displaying  successive  frames  in  a  scene.  The  faster  the 
update  rate,  the  more  continuous  the  motion  appears.  As  a  reference,  standard 
motion  picture  film  is  projected  at  a  rate  of  twenty-four  frames  per  second. 
Although  the  IRIS  workstation  is  capable  of  displaying  up  to  sixty  frames  per 
second,  the  amount  of  computation  that  must  be  done  between  successive  frames 
in  the  simulation  has  limited  the  update  rate  to  an  average  of  three  frames  per 
second.  While  thiB  presents  a  less  than  smooth  motion,  it  is  felt  to  be  adequate 


for  the  purposes  of  the  prototype. 


C.  ORGANIZATION 


The  above  sections  of  this  chapter  have  provided  background  on  flight 
simulation  in  general,  and  the  missile  whose  flight  is  specifically  being  simulated. 
Chapter  II  provides  an  overview  of  the  hardware  used  in  running  the  simulation. 
The  structure  and  content  of  the  Defense  Mapping  Agency  (DMA)  Digital 
Terrain  Elevation  Data  (DTED)  are  discussed  in  Chapter  III.  Chapter  IV 
discusses  the  motivation  behind  and  creation  of  the  two-dimensional  contour  map 
displays.  Chapter  V  covers  the  storage  and  use  of  the  DMA  DTED  to  produce  a 
lighted  an  !  shaded  three-dimensional  polygonal  terrain  display.  The  mathematics 
and  process  involved  in  simulating  flight  over  the  terrain  are  detailed  in  Chapter 
VI.  Chapter  VII  discusses  the  creation,  insertion,  animation,  and  designation  of 
targets.  Chapter  VIII  covers  the  creation  and  drawing  of  cultural  features. 
Chapter  DC  contains  a  user’s  guide  for  operation  of  the  FOG-M  simulator. 
Chapter  X  concludes  with  a  discussion  of  limitations,  future  extensions  and 
research  topics,  and  summarizes  the  research  conducted.  Narrative  descriptions  of 
the  modules  and  listings  of  the  program  source  code  for  each  of  the  modules  are 
included  as  Appendices  A  and  B  respectively. 
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II.  COMPUTER  SYSTEM 


As  discussed  in  Chapter  I,  flight  simulators  are  nothing  new.  The  significance 
of  this  work  lies  in  the  speed  with  which  it  was  developed,  the  display  rate 
achieved,  and  the  realism  and  fidelity  of  the  display  in  comparison  to  the  cost  of 
the  system  that  supports  it.  This  project  was  technically  feasible  only  because  of 
the  capabilities  and  high  performance  of  the  IRIS  (Integrated  Raster  Imaging 
System)  Turbo  2400  Graphics  Workstation,  manufactured  by  Silicon  Graphics, 
Incorporated.  Others  have  also  used  the  IRIS  as  a  base  on  which  to  build  flight 
simulators  [Ref.  6).  This  low-cost  ($50,000  to  $100,00)  three-dimensional  display 
system  is  summarized  in  Figure  2.1  and  is  discussed  more  fully  below. 


A.  HARDWARE  AND  SYSTEM  OVERVIEW 

The  IRIS  has  a  conventional  Von  Neumann  type  computer  architecture  but 
adds  custom-built  special  purpose  VLSI  circuits  and  a  pipelined  design  to  provide 
the  graphics  functions  that  are  implemented  in  software  on  other  comparably- 
priced  workstations.  Conceptually,  there  three  pipelined  components  in  the  IRIS 
hardware:  the  applications/graphics  processor,  the  Geometry  Pipeline,  and  the 
raster  subsystem  [Ref.  7:p.  1-lJ.  The  applications/graphics  processor  is  a 
conventional  Motorola  MC68020  processor  running  at  16.7  MHz.  This  processor 


runs  the  applications  program(s)  within  a  UNIX  System  V  operating  system. 


•  33  bit  16.7  MBs  Motorola  MC68030  CPU 

•  6  Megabyte*  of  CPU  Mtaory 

•  33  1034x768  bitplanes  of  Display  Memory 

•  Hardware  aatrix  aultipliar  ft  floating  point  accelerator 

•  Hardware  Gouraud  shading,  depth  cueing  k  beck fee*  polygon  reeotal 

TH 

•  13  pipelined  custoa  VLSI  Geometry  Engines 

•  16-bit  Z-buffer  for  Hidden  Surface  Elimination 
e  3  73  Megabyte  Winchester  Disk  Drives 

•  60  Hs  non- inter lacsd  19”  RGB  high  resolution  monitor 

•  83  key  up-down  encoded  keyboard 

•  3  button  mouse 

•  33-button  and  8-dial  valuator  boxen 

•  Unix  System  V 

•  Ethernet  to  VAX’s 

•  IRIS  Graphics  Library 


Features  of  the  IRIS  Turbo  2400  Graphics  Workstation 

Figure  2.1 


Applications  either  issue  graphics  commands  in  immediate  mode,  in  which  case 
they  are  sent  through  the  Geometry  Pipeline  immediately  as  individual  graphics 
primitives,  or  compile  graphics  commands  into  graphical  object *,  in  which  case 
they  are  sent  through  the  Geometry  Pipeline  as  a  single  geometric  entity  when 
explicitly  called  at  some  later  point  in  time. 

The  Geometry  Pipeline  takes  commands  in  terms  of  the  user’s  world 
coordinates,  performs  specified  matrix  transformations  on  them  using  the  matrix 
multiplier  and  floating  point  accelerator  built  into  the  hardware,  and  then  clips 
and  scales  the  transformed  coordinates  into  screen  coordinates.  The  raster 
subsystem  takes  the  screen  coordinates  output  by  the  Geometry  Pipeline  and 
updates  the  bitplancs  (display  memory)  to  contain  the  lines,  polygons,  or 
characters  specified  by  the  input  coordinates.  The  raster  subsystem  also  performs 
polygon  fill,  shading,  depth-cueing,  and  hidden  surface  removal.  A  conventional 
video  controller  uses  the  values  in  the  bitpianes  and  the  color  table  to  produce  an 
image  on  the  monitor. 

B.  SOFTWARE 

The  C  programming  language  is  native  to  UNIX  and  is  the  language  used  for 
all  of  the  IRIS  system  software.  The  IRIS  Graphics  Library,  which  provides  both 
high-  and  low-level  graphics  and  utility  commands,  can  be  called  in  C, 
FORTRAN,  Pascal,  or  LISP.  However,  due  to  the  built-in  bias  of  UNIX  and  the 
IRIS,  plus  the  local  pool  of  knowledge,  the  C  programming  language  was  the 


pro  forma  choice  for  programming  all  parts  of  the  FOG-M  simulator.  The  IRIS 
User’s  Guide  [Ref.  7]  breaks  the  Graphics  Library  commands  into  the  following 
twelve  categories: 

-  Global  State  commands  initialize  the  hardware  and  control  global  variables, 
and  are  used  mostly  in  FOG-M’s  init  iris  routine. 

-  Drawing  Primitives  are  used  throughout  FOG-M.  They  create  points,  lines, 
polygons,  circles,  arcs,  and  text  strings. 

-  Coordinate  Transformations  specify  mappings  within  and  between  user- 
defined  world  coordinates  and  screen  coordinates.  These  are  used  to  move 
targets  and  to  simulate  flight. 

-  Drawing  Attribute  commands  specify  textures  and  fonts.  Although  texture 
would  greatly  improve  the  appearance  of  the  terrain,  the  IRIS  provided 
textures  are  applied  in  the  screen  coordinate  system,  so  they  do  not  scale  or 
tilt  to  conform  to  the  terrain,  and  produce  a  very  artificial  result. 

-  Display  Mode  and  Color  commands  determine  how  the  bitplanes  are  used 
and  what  colors  appear  on  the  screen.  These  include  the  commands  that  set 
double-buffering,  establish  writemasks,  and  define  the  color  table. 

-  Input  /  Output  commands  initialize  and  read  the  dials  and  mouse. 

-  Object  Creation  and  Editing  commands  allow  manipulation  of  complex 
displays  as  a  single  entity.  They  are  used  in  all  FOG-M  displays. 

-  Picking  and  Selecting  commands  are  not  used  in  FOG-M. 

-  Geometry  Pipeline  Feedback  commands  are  not  used  in  FOG-M. 

-  Curve  and  Surface  commands  draw  complex  curves  and  smooth  surfaces. 
Experiments  with  these  produced  more  realistic  terrain  images,  but  not  even 
close  to  real-time,  making  flight  animation  impossible. 

-  Shading  and  Depth-cueing  commands  provide  Gouraud  shading  of  polygons 
and  intensities  that  vary  with  distance  from  the  viewer. 

-  Textport  commands  define  an  area  of  the  screen  for  text.  They  are  not  used 
in  FOG-M. 

Also  available  on  the  system,  and  used  by  FOG-M,  are  the  math  library  with 
sine,  cosine,  arctangent,  hypotenuse,  and  exponentiation  functions,  and  routines 
that  access  the  system  clock  in  order  to  determine  elapsed  time. 


ni.  DIGITAL  ELEVATION  TERRAIN  DATA 


A.  INTRODUCTION 

Unlike  other  flight  simulation  systems,  which  may  rely  on  manual  creation  of 
the  terrain  [Ref.  8],  the  source  data  for  the  terrain  in  the  FOG-M  simulation  is  a 
Defense  Mapping  Agency  (DMA)  digital  terrain  elevation  database  (DTED)  for 
Fort  Hunter-Liggett,  California.  The  database  is  not  Level  1  DTED,  but  rather  a 
DMA  special  product  produced  about  1980  at  a  higher  resolution  than  normal 
Level  1  DTED  [Ref.  9],  Level  1  DMA  data  contains  elevation  points  spaced  at 
three  arc-second  intervals,  or  approximately  every  one  hundred  meters.  The  Fort 
Hunter-Liggett  special  data  contains  points  at  twelve  and  one-half  meter  spacing, 
which  is  eight  times  the  resolution  of  Level  1  data. 

B.  COVERAGE 

The  area  covered  by  the  database  is  thirty-six  kilometers  wide  and  thirty-five 
kilometers  high,  with  6400  data  points  per  square  kilometer.  This  area  includes 
most  of  Fort  Hunter-Liggett  plus  some  surrounding  land,  and  is  bounded  by 
latitudes  36°  05 '00"  (to  the  north)  and  35°  50' 00"  (south)  and  longitudes 
121°  04'  30"  (east)  and  121°  20'  30"  (west).  In  terms  of  Universal  Transverse 
Mercator  (UTM)  coordinates,  the  area  has  easting  ( X )  of  10SFQ41000  to 
10SFQ77000  and  northing  (K)  of  10SFQ60000  to  10SFQ95000.  The  database 
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mx, 


appears  to  be  based  on  DMA  forty  foot  interval  contour  map  products,  because 
peaks  tend  to  have  flattened  tops.  This  was  confirmed  both  by  a  comparison  of 
surveyed  instrumentation  sites  on  or  near  peaks  with  their  digital  terrain  values 
[Ref.  10:  pp.  1-2],  and  by  a  Bezier  surface  patch  image  of  the  data  created  locally. 

C.  STRUCTURE 

The  data  is  stored  in  an  unformatted  sequential  file  that  is  organized  as  a 
stream  of  integers.  Each  integer  (sixteen  bits)  represents  both  the  vegetation  code 
and  bald  terrain  elevation  in  feet  at  one  sampling  point,  as  illustrated  in  Figure 
3.1  below. 


Veg.  Code 

Bald  Terrain  Elevation 

bit: 

15  14  13 

12  11  10  9876543210 

Figure  3.1  DTED  Data  Encoding 


The  thirteen  low-order  (rightmost)  bits  contain  the  elevation,  allowing  a  range 
from  zero  to  8191  feet,  although  the  highest  point  in  the  database  is  3744  feet. 
The  three  high-order  (leftmost)  bits  specify  one  of  eight  vegetation  codes,  which 
are  given  in  Table  3.1  below.  Vegetation  codes  are  only  available  for  points 
within  the  boundaries  of  Fort  Hunter-Liggett  proper.  The  file  is  written  one 


TABLE  3.1  DTED  VEGETATION  CODES 


lifff 

Description 

Less  than  one  meter 

One  to  four  meters 

Four  to  eight  meters 

Eight  to  twelve  meters 

Twelve  to  twenty  meters 

5 

Greater  than  twenty  meters 

6 

No  data  available 

7 

Unused 

square  kilometer  at  a  time,  beginning  with  the  lower  left  one  kilometer  grid  square 
(41,60),  proceeding  up  the  column  to  the  upper  left  grid  square  (41,04),  then 
doing  the  next  column  from  bottom  to  top  (42,60  to  42,04)  and  so  on;  the  upper 
right  one  kilometer  grid  square  (76,04)  is  the  last  one  written.  Within  each  one 
kilometer  grid  square,  the  individual  data  points  are  written  in  the  same  pattern, 
beginning  with  the  lower  left,  doing  each  column  from  bottom  to  top,  and  doing 
the  columns  from  left  to  right.  This  file  layout  is  summarized  in  Figure  3.2.  The 
position  in  the  file  of  the  elevation  for  a  point  expressed  in  five  digit  local  UTM  X 
and  Y  coordinates  is  found  as  shown  in  Equation  3.1. 


position  =  35  *  (integer  (X/ 1000)  -  41)  +  (integer (Y/ 1000)  -  59)  (3.1) 


D.  LOCATION 

The  complete  DTED  file  occupies  16,128,000  bytes  of  storage.  Due  to  a  local 
shortage  of  available  disk  space,  this  file  must  permanently  reside  on  the  UNIX 
VAX  11/785  system  rather  than  on  the  IRIS  system.  The  FOG-M  simulator 
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presently  operates  on  a  ten  kilometer  square  extract  from  this  database.  A 
program  on  the  VAX  called  make— database— e  allows  interactive  specification 
of  the  area  and  resolution  desired,  and  produces  an  extract.  This  extract  is  sent 
over  the  Ethernet  to  the  IRIS  to  serve  as  the  input  for  a  FOG-M  run.  However,  if 
the  data  is  sent  directly,  it  is  received  with  each  pair  of  bytes  swapped,  so  another 
program,  swapdma,  is  run  on  the  VAX  before  transmittal.  This  program  swaps 
the  low-  and  high-order  bytes  of  each  integer  so  that  the  swapping  during 
transmission  is  cancelled. 
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IV.  TWO-DIMENSIONAL  TERRAIN  MAP  PORTRAYAL 


The  two-dimensional  representation  of  the  terrain  was  begun  as  the  first 
graphics  portion  of  the  system,  in  order  to  gain  familiarity  with  the  IRIS  graphics 
workstation  and  the  Defense  Mapping  Agency  (DMA)  digital  terrain  elevation 
data  (DTED).  Contour  maps  are  the  traditional  approach  to  two-dimensional 
terrain  portrayal,  and  thus  were  the  basis  for  the  two-dimensional  images  of  the 
terrain  generated  here  (Figure  4.1).  Although  these  two-dimensional  images  are 
not  true  contour  maps,  they  are  still  referred  to  as  such  in  this  study  because  of 
their  close  relation  and  common  origin.  The  algorithms  for  determining  and 
drawing  the  forty  foot  contour  lines  found  on  a  normal  contour  map  seemed  non¬ 
trivial,  so  a  simpler  alternative  was  chosen.  Each  elevation  datum  is  represented 
by  a  tile,  with  the  implicit  X  and  Z  (easting  and  northing,  respectively) 
coordinates  of  the  elevation  datum  being  the  center  of  the  tile. 

A.  COLORS 

The  color  of  a  tile  is  determined  by  its  vegetation  code,  and  its  intensity  (or 
shading)  by  its  elevation.  The  intent  was  to  use  green  for  tiles  with  vegetation 
and  brown  for  tiles  without  vegetation.  However,  the  DTED  vegetation  codes 
lump  together  both  “no  vegetation”  and  “vegetation  less  than  one  meter  high.” 
Brown  tiles  thus  include  both  unvegetated  areas  (e.g.  rock  slabs,  areas  above  the 


25 


Figure  4.1  Simulator  Contour  Map  Display 


treeline)  and  grasslands  or  meadows.  This  is  significant  in  the  Fort  Hunter- 
Liggett  area,  because  most  of  the  valleys  are  covered  in  grass,  and  all  of  the  high 
ground  is  below  the  treeline.  The  result  is  a  map  with  brown  valleys  and  green 
ridgelines.  While  this  was  readily  accepted  as  natural  by  most  viewers,  pilots 
with  a  background  in  low-level  flight  found  it  awkward,  and  contrary  to  their 
expectations  (from  flight  charts)  of  green  valleys  and  brown  mountains.  While 
this  might  be  significant  in  other  flight  simulation  applications  (particularly  those 
designed  for  pilots),  the  initial  representation  was  deemed  most  appropriate  for 
the  target  audience  of  the  FOG-M  simulator. 

A  similar  initial,  intuitive  choice  was  made  for  the  elevation-keyed  shading. 

High  intensity  (light)  colors  were  used  for  higher  elevations,  and  low  intensity 

(dark)  colors  for  lower  elevations.  This  was  accepted  as  natural  by  almost  all 

viewers.  The  optimum  number  of  intensities  (shadings)  to  use  in  the  map  was 

experimentally  determined  to  be  sixteen.  A  small  power  of  two  was  desirable  due 

to  the  nature  of  the  writemasks  used  to  improve  display  speed.  A  large  number  of 

colors  provides  greater  elevation  definition  and  prevents  large  masses  of  the  same 

color  in  areas  where  elevations  change  gradually.  However,  having  too  many 

colors  destroys  the  contour-map  effect,  since  adjacent  colors  are  so  close  that  no 

boundary  is  distinguishable  between  them.  Eight  shades  each  of  green  and  brown 

were  used  initially.  The  shift  to  sixteen  shades  of  each  produces  a  better  looking 

map.  Due  to  the  RGB  (red,  green,  blue)  nature  of  color  creation  on  the  IRIS,  the 

greens  were  still  barely  differentiable  at  thirty-two  shades,  but  the  browns  (a 
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combination  of  mostly  red,  some  green,  and,  in  some  shades,  a  trace  of  blue) 
began  to  blend  together. 

To  determine  the  elevations  at  which  color  shades  should  change  (in  order  to 
use  the  full  range  of  shades),  the  maximum  and  minimum  elevations  of  the 
terrain  section  in  use  must  be  known.  Rather  than  preprocess  the  data  before  each 
run,  these  values  are  coded  as  constants  in  a  header  file.  The  equation  for  which 
color  index  to  use  is  straightforward  (see  Equation  4.1)  but  takes  significant  time 
when  repeated  ten  thousand  times. 

elevation- MIN 

index  =  bast  index  +  -  *  #  of  shades  (4.1) 

MAX-  MIN 

Therefore,  the  fifteen  points  at  which  the  shade  changes  are  precalculated  and 
stored  in  an  array  so  that  no  calculations  are  needed  at  each  point,  just  an  array 
lookup. 

B.  DRAWING 

The  map  can  then  be  produced  by  determining  the  color  and  shade  for  each 
tile,  and  drawing  it  as  a  filled  square.  However,  an  increase  in  speed  can  be  gained 
by  exploiting  the  structure  of  the  data  and  the  line  drawing  hardware  of  the  IRIS. 
The  data  is  still  processed  a  point  at  a  time  within  each  one  kilometer  column, 
but  no  drawing  is  done  until  an  elevation/shading  breakpoint  is  reached.  Then  a 
single  line  of  one  tile’s  width  is  drawn  to  color  all  tiles  since  the  previous  elevation 


breakpoint. 


C.  WRITEMASKS 


A  more  significant  speed  improvement  (on  the  order  of  fifty  per  cent  more 
frames  per  second)  was  achieved  with  writemasks.  Writemasks  are  a  relatively 
low-level  hardware  feature  that  can  be  used  for  many  purposes.  In  the  FOG-M 
simulator,  they  are  used  to  prevent  the  contour  map  from  being  overwritten. 
This  allows  the  map  to  be  drawn  only  once  into  the  bitplanes,  and  have  it  remain 
on  the  screen  without  being  re-drawn  during  each  frame  update.  In  order  to 
understand  how  writemasks  work,  one  must  understand  the  layout  and  use  of  the 
IRIS’s  color  table  and  bitplanes. 

1.  Color  Table 

The  color  table  associates  a  particular  binary  number  with  a  color. 
When  the  display  system  asks  what  color  some  number  is,  the  color  table  replies 
with  the  intensities  for  the  red,  green  and  blue  color  guns  that  will  produce  the 
color  defined  for  the  input  number.  This  input  number  is  referred  to  as  a 
colorindex.  Thus  the  color  displayed  on  the  screen  depends  on  the  colorindex 
associated  with  a  given  pixel,  and  the  color  associated  with  that  colorindex  in  the 
color  table.  Table  4.1  gives  the  color  table  entries  that  are  the  defaults  on  the 
IRIS  workstation. 

2.  Bitplanes 

The  colorindex  that  is  associated  with  each  pixel  is  stored  in  the  display 
memory,  which  is  composed  of  bitplanes.  Each  bitplane  has  one  bit  for  each  pixel 
on  the  display  screen,  so  a  bitplane  is  1024  bits  wide,  768  bits  high  and  one  bit 


TABLE  4.1  IRIS  DEFAULT  COLORINDEX  DEFINITIONS 


Color 

Colorindex 

Decimal 

Binary 

Black 

0000000000000000 

Red 

1 

0000000000000001 

Green 

2 

0000000000000010 

Yellow 

3 

0000000000000011 

Blue 

4 

0000000000000100 

Magenta 

5 

0000000000000101 

Cyan 

6 

0000000000000110 

White 

7 

0000000000000111 

deep.  When  used  in  double-buffer  mode  (as  in  FOG-M),  the  IRIS  uses  sixteen 
bitplanes  (numbered  0  to  15)  for  each  buffer.  The  f rontbuf f er  is  the  one  whose 
binary  contents  define  the  image  being  displayed.  While  the  frontbuffer  is  being 
displayed,  the  next  image  is  created  by  issuing  drawing  commands  which  affect 
only  the  baekbuffer.  Once  a  new  image  is  completed  in  the  backbuffer,  the 
buffers  are  swapped ,  so  the  backbuffer  becomes  the  frontbuffer  and  is  displayed. 
The  old  frontbuffer  becomes  the  backbuffer,  and  is  then  available  for  update. 

3.  Writemask  Example 

Consider  the  pixel  at  location  (0,0)  -  the  lower  left  corner  of  the  screen. 
The  colorindex  of  that  pixel  is  determined  by  sixteen  bits:  one  from  the  lower  left 
corner  of  each  bitplane.  The  display  system  reads  those  sixteen  bits  as  a  binary 
number  (the  colorindex),  and  uses  the  color  table  to  determine  what  color  to 
make  that  pixel.  For  example,  using  the  default  colors  defined  in  Table  4.1  above, 


that  pixel  will  be  colored  black  if  all  sixteen  bitplanes  have  zeroes  in  their  lower- 


left  corners,  since  the  value  of  the  sixteen  bit  binary  number  00000000000000002  is 
zero.  If  the  current  color  is  set  to  magenta  (color  five,  whose  binary  value  has  ones 
in  bits  zero  and  two)  and  a  drawing  command  is  issued,  bitplanes  zero  and  two 
are  set  to  one,  and  all  other  bitplanes  are  set  to  zero,  for  every  pixel  covered  by 
the  drawing  command.  These  pixels  will  now  be  displayed  as  magenta,  because 
the  colorindex  constructed  from  the  sixteen  bitplanes  will  be  00000000000001012 
(510),  and  the  color  table  tells  the  display  system  that  color  510  is  magenta. 

The  previous  example  showed  that  a  drawing  command  works  by 
placing  ones  in  certain  bitplanes,  and  zeroes  in  all  of  the  rest,  with  the  current 
color  specifying  which  bitplanes  get  which.  A  writemask  tells  each  bitplane  to 
either  allow  or  ignore  the  changes  a  drawing  command  says  to  make.  In  normal 
double-buffered  usage,  the  writemask  is  meaning  all  sixteen 

bitplanes  should  allow  updates.  Now  suppose  there  is  an  image  on  the  screen 
which  uses  just  the  default  eight  colors.  Bitplanes  three  through  fifteen  are  all 
zeroes,  because  all  of  the  colors  have  colorindices  with  three  or  less  binary  digits, 
which  will  be  in  bitplanes  zero,  one,  and  two.  If  the  writemask  is  changed  to 
111  11111111 110002  after  drawing  the  image,  those  lower  three  bitplanes  are 
“frozen”  and  will  not  be  changed  by  any  drawing  command.  Setting  the  color  to 
black  and  clearing  the  screen  will  not  change  anything.  The  upper  bitplanes  will 
be  set  to  all  zeroes,  which  they  already  were.  The  lower  three  bitplanes  will  be 
told  to  reset  to  zero,  but  will  not  do  it  because  they  are  protected  by  the 


writemask. 


Now  suppose  you  want  to  draw  a  grey  line  on  top  of  the  image.  The  line 
only  needs  one  color,  so  it  can  be  drawn  in  one  bitplane.  (Two  bitplanes  will  allow 
three  more  colors  on  top  of  the  map,  three  bitplanes  allow  seven,  etc.)  The  first 
"free"  bitplane  is  number  three.  Turning  on  a  bit  in  this  plane  (and  not  turning 
on  any  bits  in  higher  planes)  requires  a  colorindex  in  the  range  10002  to  1 1 1 12  (8I0 
to  1510).  Defining  color  eight  in  the  color  table  as  grey,  making  color  eight  the 
current  color,  and  then  drawing  the  line  is  sufficient  to  get  the  image  into  the 
bitplanes,  but  the  display  will  not  show  the  desired  effect.  If  the  image 
underneath  the  line  is  black  (i.e.  bitplanes  zero  through  two  are  all  zeroes  form 
some  pixels),  the  line  will  appear  grey,  as  intended,  for  those  pixels.  However,  if 
the  image  underneath  the  line  is  red  (i.e.  the  lower  bitplanes  contain  0012),  the 
composite  colorindex  retrieved  by  the  display  system  is  000000000000 100 12  or  910) 
and  since  color  nine  is  not  defined  in  the  color  table,  it  appears  as  black.  Thus 
every  colorindex  that  has  bit  three  (because  the  line  is  in  bitplane  3)  set  to  one 
(i.e.  colorindices  10002  to  11112,  or  8,0  to  15]0)  must  be  defined  as  grey  in  order  to 
produce  the  desired  image. 

4.  Writemasks  in  FOG-M 

The  map  image  used  in  FOG-M  is  stored  in  the  first  six  bitplanes 
(numbered  0  through  5)  of  both  buffers,  which  means  sixty-four  colors  are 
available:  eight  are  the  IRIS  defaults,  sixteen  are  shades  of  brown,  sixteen  are 
shades  of  green,  and  twenty-four  are  unused.  The  writemask  defined  as 

SAVEMAP  (C0lfl  or  000000001 10000002)  allows  things  to  be  drawn  on  top  of  the 
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map  in  bitplanes  six  and  seven.  Coiorindices  64  through  127  are  all  defined  as 
blue  in  the  color  table,  so  anything  drawn  in  bitplane  six  appears  on  top  of  the 
map  in  blue.  Similarly,  bitplane  seven  is  used  for  red,  with  coiorindices  128 
through  255  all  correspondingly  defined  to  be  red. 

The  speed  improvement  due  to  writemasks  in  FOG-M  comes  from  not 
having  to  re-draw  the  map  each  time  the  screen  is  updated.  The  cost  is  the  use  of 
many  more  indices  in  the  color  table,  which  limits  the  number  of  colors  available 
for  use  on  top  of  the  map.  For  our  simulation  system,  with  only  two  colors 
needed  on  top  of  the  map,  there  is  plenty  of  room  in  the  color  table.  Therefore, 
the  gain  in  speed  comes  at  no  real  cost. 


V.  THREE-DIMENSIONAL  TERRAIN  CONSTRUCTION 


A.  REPRESENTATION  DECISIONS 
1.  Polygons  versus  Patches 

Early  experiments  in  the  study  involved  attempting  to  display  the 
terrain  using  parametric  bi-cubic  surface  patches.  A  surface  patch  is  simply  a 
smooth  curved  surface  fitted  to  a  set  of  data  points.  A  discussion  of  the  theory 
and  use  of  surface  patches  can  be  found  in  the  IRIS  User’s  Guide  [Ref.  7:sec.  11-3) 
and  Hearn  and  Baker  [Ref.  ll:pp.  193-205).  It  was  quickly  determined  that  it 
would  not  be  possible  to  use  surface  patches  to  represent  the  terrain  and  still 
maintain  a  real-time  update  of  the  terrain  during  flight. 

An  alternate  method  of  displaying  a  three-dimensional  object  is  through 
the  use  of  a  set  of  planar  polygon  surfaces  that  join  at  common  edges  to  form  the 
terrain  object.  This  method  has  the  advantage  of  being  much  simpler,  and 
therefore  faster,  to  generate  and  display.  For  this  reason  it  was  chosen  for  use  in 
the  project. 

Figure  5.1  shows  the  method  of  constructing  the  terrain  surface  as  a  set 
of  triangles.  The  term  gridsquarc  is  used  in  the  remainder  of  the  chapter  to  refer 
to  a  set  of  two  triangles  with  a  common  hypotenuse  that  form  a  square  of  the 


terrain  grid. 


2.  Resolution 


The  special  DMA  data  file  used  in  this  project  contains  elevation  data 
that  is  spaced  at  a  twelve  and  one- half  meter  interval.  One  of  the  first  questions 
which  had  to  be  answered  concerning  the  three-dimensional  portrayal  of  this  data 
was,  “In  how  fine  a  resolution  can  the  data  be  displayed,  while  still  allowing  for  a 
sufficient  frame  update  speed?”  Early  test  runs  showed  that  using  the  full  twelve 
r  id  one-half  meter  resolution  would  be  much  too  slow,  although  it  provided  an 
excellent  representation  of  the  terrain.  An  adequate  frame  update  rate 
(approximately  three  to  four  frames  per  second)  was  achieved  with  a  seventy-five 
meter  resolution  or  every  sixth  data  point.  Since  this  was  an  early  test,  displaying 
terrain  without  any  targets  or  cultural  features,  a  one  hundred  meter  resolution 
was  decided  upon  for  use  in  the  remainder  of  the  project.  This  allowed  for  an 
adequate  “cushion”  of  processing  time  to  complete  the  additional  computations 
that  would  be  needed  in  the  final  product,  while  still  providing  an  adequate 
degree  of  resolution. 

3.  Elevation  Scaling 

After  viewing  the  early  representations  of  the  terrain,  it  appeared  that 
the  hills  did  not  give  an  appropriate  appearance  of  height.  Although  this  was  a 
subjective  judgement,  it  was  shared  by  most  people  who  viewed  the  display  and 
compared  it  to  aerial  photographs  of  the  area.  Because  of  this,  it  was  decided  to 
scale  the  elevations  of  the  displayed  points  upward.  Two  approaches,  linear 
scaling  and  exponential  scaling,  were  examined. 


In  the  linear  scaling  approach,  each  elevation  point  was  simply 
multiplied  by  a  scale  factor  as  shown  in  Equation  5.1. 

Elevnn,  =  °  *  tUvoU  (51) 

Using  this  approach,  it  appeared  that  a  scaling  factor  between  1.5  and  2.0  was 
necessary  to  achieve  the  desired  effect. 

In  the  exponential  approach,  the  elevation  of  each  point  was  raised  to  a 
fixed  power  as  shown  in  Equation  5.2. 

=  Elev'u  (5-2) 

This  approach  has  the  effect  of  exaggerating  the  higher  elevations  to  a  greater 
degree  than  the  lower  ones.  It  was  chosen  as  the  approach  for  use  in  the  project 
based  on  subjective  observations  of  the  displays  produced  by  the  two  methods. 
The  scaling  factor,  <r,  was  chosen  as  1.05.  Using  this  factor  produces  the 
equivalent  of  a  linear  scaling  of  1.5  for  the  maximum  elevation  and  1.4  for  the 
minimum  elevation  contained  in  our  area  of  interest. 

Subsequent  to  the  decision  to  use  an  exaggerated  elevation  scale, 
research  results  were  discovered  which  supported  it.  In  a  study  conducted  by  the 
U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences,  observers 
were  asked  to  pick  a  computer  generated  line  drawing  that  best  matched  actual 
terrain.  The  line  drawings  had  different  exaggerations  of  the  vertical  (elevation) 
scale.  The  overall  ratios  chosen  by  the  four  observers  ranged  from  1.25:1  to 


1.50:1.  The  drawings  presented  to  the  observers  had  exaggeration  ratios  ranging 
from  1:1  to  1.75:1.  [Ref.  12] 

4.  Shading  and  Texturing 

As  explained  above,  each  one  hundred  meter  square  of  the  terrain,  a 
“gridsquare,  ”  is  represented  by  two  triangles  in  three-space  that  share  a  common 
diagonal  edge.  The  process  of  applying  colors  to  these  polygons,  shading,  was  the 
next  area  of  research  in  the  project. 

a.  Elevation  Baaed  Shading 

Three  different  shading  algorithms  were  investigated.  The  first  was 
a  simple  algorithm  where  the  shade  of  a  polygon  was  a  function  of  its  elevation. 
Higher  elevations  are  shaded  in  lighter  shades  of  green  while  lower  elevations 
receive  darker  shades.  Equation  5.3  represents  the  assignment  of  a  shade  from  the 
color  map. 

elev  -  MinElev 

color  index  -  bast  inde.z  +  - “ -  *  ft  of  shadcs  (5.3) 

MaxElev  -  \fin_Elev 

The  darkest  green  is  stored  in  the  base  index  color  map  location  and  the  lightest 
green  in  the  baseindex  +  #  of  jihades  location.  Although  this  approach  works 
well  for  two-dimensional  contour  maps  (see  Chapter  IV),  and  is  currently  used  in 
another  “low  cost”  simulator  [Ref.  6],  it  did  not  appear  to  present  a  realistic  view 
of  the  terrain.  An  advantage  of  this  approach,  however,  is  that  the  calculation  of 
the  color  index  is  simple  enough  to  be  done  with  no  preprocessing. 


b.  Lambert  s  Cosine  Law  Shading 

The  second  method  of  determining  the  shade  for  a  polygon  involved 
the  use  of  a  point  light  source  and  Lambert’s  cosine  law  [Ref.  ll:p.  278].  Let  ft 
be  a  unit  normal  vector  to  the  polygon,  and  Z  be  a  unit  vector  in  the  direction  of 
the  light  source.  The  angle  between  ft  and  L,  9,  is  the  angle  of  incidence. 
Lambert’s  Law  states  that  the  intensity  of  the  light  reflected  from  the  polygon  is 
proportional  to  cos  ♦  (Equation  5.4). 

I  a  cos  0  (5.4) 

In  order  to  use  this  law,  the  normal  vector  ($),  the  light  source  vector  (L),  and 
the  angle  between  them  (♦)  must  be  known.  ft  can  be  determined  by  taking  the 
cross  product  of  vl  and  v2,  where  t>l  is  a  unit  vector  in  the  direction  from  vertex 
B  to  vertex  C  of  the  polygon,  and  v2  is  &  unit  vector  in  the  direction  from  vertex 
B  to  vertex  A  of  the  polygon  (Equation  5.5  and  Figure  5.2). 

ft  =  t/1  x  vi  (5.5) 

With  ft  and  Z  available,  cos  ♦  can  be  computed  as  their  dot  product  (Equation 


*  =  ft-Z 


Since  the  intensity  is  proportional  to  cos  4,  the  appropriate  color  index  to  use  can 


be  computed  as 


color  index  =  min  index  +  (#  shades* cos  ♦) 


where  min  index  is  the  color  index  of  the  lowest  intensity  green  and 
min  index  +  #  shades  is  the  color  index  of  the  highest  intensity  green, 
c.  Gouraud  Shading 

The  final  shading  model  investigated  involved  the  use  of  Gouraud 
shading.  The  purpose  of  Gouraud  shading  is  to  provide  a  continuous  transition  of 
shades  across  a  polygon  so  that  the  shades  at  the  edges  of  adjoining  polygons 
match.  This  in  effect  eliminates  the  visible  boundary  between  polygons  and 
provides  a  smooth  continuous  surface.  The  Gouraud  algorithm  involves 
interpolating  to  determine  the  intensity  to  be  used  at  each  pixel  along  a  scan  line, 
and  is  illustrated  in  Figure  5.3  as  reproduced  from  Hearn  and  Baker  [Ref.  ll:p. 
290].  To  use  the  algorithm,  intensity  values  for  each  vertex  of  the  polygon  must 
be  known.  In  the  project’s  implementation,  the  intensity  at  each  vertex  was 
computed  as  the  average  of  the  intensity  values  for  all  the  polygons  meeting  at 
that  vertex,  where  the  individual  polygon’s  intensity  v&lues  were  calculated  using 
Lambert’s  cosine  law. 

The  use  of  this  model  posed  two  problems.  First,  even  though  the 
IRIS  supports  Gouraud  shading  in  its  graphics  library,  its  use  increased  the  time 
between  frames  to  an  unacceptable  rate  (approximately  one  and  one-half  to  three 
seconds  between  frames).  Second,  the  smoothing  of  the  algorithm  worked  too 
well,  resulting  in  terrain  displays  that  lacked  the  necessary  position  cues  to  detect 
motion.  This  second  problem  could  be  alleviated  by  adding  artificial  texture  to 
the  terrain  but  in  light  of  the  speed  problem  it  was  not  pursued  further. 


For  interpolated  shading,  the  intensity  value 
at  point  4  is  determined  from  intensity  values 
at  points  1  and  2,  intensity  at  point  6  is 
determined  from  values  at  points  2  and  3,  and 
intensities  at  other  points  (such  as  5)  along 
the  scan  line  are  interpolated  between  the 
values  at  points  4  and  6. 


Figure  5.3  The  Gouraud  Shading  Algorithm 


d.  Adding  Texture 

Lambert’s  cosine  law  was  chosen  as  the  shading  model  for  use  in  the 
project,  providing  the  most  realistic  display  within  the  allowed  computation  time 
constraints.  However,  a  problem  with  its  use  is  that  the  flat  valleys,  with  little 
variance  in  the  surface  normals  of  their  polygons,  produce  large  geographic  areas 
having  a  near  constant  shade.  This  results  in  a  lack  of  motion  cues  in  these  areas 
similar  to  that  experienced  with  the  Gouraud  shading  model.  To  remedy  this 
situation,  a  simple  artificial  texture,  in  the  form  of  a  checker  board,  was  imposed 
on  the  terrain.  The  checker  board  effect  was  implemented  as  follows.  First,  the 
shades  for  the  two  triangles  in  each  gridsquare  were  averaged,  and  this  average 
shade  was  used  for  both  of  them.  This  of  course  causes  the  visible  boundary 
between  the  triangles  to  disappear  leaving  a  square  shaded  in  a  single  color. 
Second,  two  slightly  offset  color  ramps  were  used  with  adjacent  grid  squares  using 
different  ramps  to  compute  their  shades.  One  ramp  is  composed  of  green 
intensities  ranging  from  255  to  50,  while  the  other  uses  intensities  ranging  from 
245  to  40.  *  This  causes  the  shades  for  two  adjacent  gridsquares  with  identical 
surface  normals  to  vary,  providing  the  necessary  texturing. 


*A  value  of  255  is  the  highest  intensity  green  obtainable,  a  value  of  zero  indicates  the  absence 
of  the  color  green 
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B.  INTERNAL  DATA  STRUCTURES 


Two  global  arrays  are  maintained  which  store  the  information  necessary  to 
display  the  terrain.  The  first  is  a  five-dimensional  array,  savetriangle ,  that  stores 
the  values  of  the  coordinates  for  each  triangle  making  up  the  terrain  structure. 
The  second  is  a  two-dimensional  array  savecolor  that  stores  the  color  map  indices 
for  each  of  the  terrain’s  grid  squares.  The  purpose  and  range  of  each  of 

savetriangle's  indices  is  shown  in  Table  5.1.  For  example, 

savetriangle  [3j[5][l][l][2]  would  contain  the  value  of  the  Y  coordinate  (fifth 
dimension  =  2),  of  the  second  vertex  (fourth  dimension  =  1),  of  the  northern 
triangle  (third  dimension  =  1),  of  the  grid  square  with  X  index  five  and  Z  index 
three  (second  dimension  =  five  and  first  dimension  =  three). 


TABLE  5.1  LAYOUT  OF  THE  SAVETRIANGLE  ARRAY 


Dimension 

Index  Range 

Purpose 

Start 

End 

First 

0 

98 

Grid  square  index  in  the  Z  direction.  0 
is  the  southern  most  square,  98  is  the 
northern  most. 

Second 

0 

98 

Grid  square  index  in  the  X  direction.  0 
is  the  western  most,  98  is  the  eastern 
most. 

Third 

0 

1 

Triangle  identifier  within  a  grid  square. 

0  is  the  southern  triangle.  1  is  the 
northern. 

Fourth 

0 

2 

Vertex  number  of  the  triangle.  0  is  the 
first  vertex,  2  is  the  last. 

Fifth 

0 

2 

Coordinate  identifier  of  the  vertex.  0  is 
the  X  coordinate,  1  the  Y  coordinate 
and  2  the  Z  coordinate. 
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Table  5.2  lists  the  purpose  and  ranges  of  each  of  aavtcolor' s  indices.  For 
example,  save  co/or  (30]  [  10]  contains  the  color  map  index  to  be  used  for  the  grid 
square  with  a  Z  index  of  thirty  and  an  X  index  of  ten. 


TABLE  5.2  LAYOUT  OF  THE  SAVECOLOR  ARRAY 


Index  Range 

Purpose 

Start 

End 

First 

0 

98 

Grid  square  index  in  the  Z  direction.  0 
is  the  southern  most  square,  98  is  the 
northern  most. 

Second 

0 

98 

Grid  square  index  in  the  X  direction.  0 
is  the  western  most,  98  is  the  eastern 
most. 

These  two  arrays  contain  all  the  information  necessary  to  construct  an  image 
of  the  terrain.  The  following  chapter  provides  the  details  of  using  their  data  to 
create  a  real-time,  updated  image  of  the  terrain  as  it  is  seen  from  the  FOG-M’s 
camera. 


VI.  FLIGHT  SIMULATION 


A.  OVERVIEW 

The  previous  chapter  discussed  the  methodology  of  constructing  the  three- 
dimensional  terrain  from  the  provided  elevation  data.  This  chapter's  purpose  is 
to  explain  the  details  of  displaying  this  terrain  in  real  time  as  it  is  seen  through 
the  missile’s  camera. 

The  high  level  pseudocode  for  the  main  program’s  terrain  display  loop  is 
shown  in  Figure  0.1.  Chapter  VII  explains  the  details  of  step  two.  The  details  of 
steps  one  and  six  are  explained  in  Appendix  B  under  the  procedures  rcadcontrola 
(for  step  one)  and  cdit  navbox  and  cditindbox  (for  step  two).  The  remainder  of 
this  chapter  discusses  the  details,  considerations,  and  results  of  implementing 
steps  three  through  five. 

B.  UPDATING  THE  MISSILE’S  POSITION 

Determining  the  missile’s  new  position  can  be  broken  into  two  cases: 

[lj  the  missile  is  under  operator  control  and  its  new  position  is  a  function  of  the 
old  position,  the  commanded  direction  of  flight,  the  commanded  altitude, 
and  the  commanded  speed. 

[2]  the  missile  is  locked  onto  a  target  and  its  new  position  is  a  function  of  its  old 
position,  the  position  of  the  desired  target,  and  the  commanded  speed. 

In  both  cases,  a  very  large  simplifying  assumption  is  made  to  ignore  the 

dynamics  of  the  missile’s  flight.  This  means  that  the  missile  is  able  to 
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While  missile  is  flying  do 

1)  Read  the  values  from  the  operator’s  controls 

2)  Determine  new  positions  for  all  the  targets 

3)  Determine  the  new  position  for  the  missile 

4)  Determine  the  position  of  where  the  camera  is  looking 

5)  Display  the  terrain  as  seen  by  the  camera 

6)  Update  the  operator’s  control  indicators 
End  while 

Figure  6.1  Main  Display  Loop  Pseudocode 

instantaneously  change  heading,  speed,  and  altitude.  This  assumption  was  made 
only  because  of  development  time  constraints.  It  is  felt  that  the  computations 
necessary  to  more  realistically  model  the  dynamics  of  the  flight  can  be  done 
without  a  serious  degradation  of  the  simulator’s  performance. 

1.  Case  1  -  Operator  Control 

Under  this  case  the  missile’s  X,  Y,  and  Z  coordinates  are  computed  as 
shown  below. 


ADiat  =  Speed*  ATinte 


(6.1) 


Where 


-  ADtst  is  the  distance  traveled  over  the  ground  since  the  last  position  was 
calculated. 

-  Speed  is  the  missile’s  speed  in  feet  per  second  and 

-  A  Time  is  the  elapsed  time  since  the  last  position  was  calculated 

Having  calculated  the  distance  the  missile  must  move  during  this  frame  the 
missile’s  new  coordinates  ( MX ,MY ,MZ )  can  be  calculated  as 

=  MX.U +l  <6-2) 

M2,,„  -  (6.3) 

Ml',..  ■  M'U/  I6-4* 

Where 

-  D'rcmd  is  the  commanded  heading  in  radians 

-  is  the  commanded  altitude  in  feet 

-  a  is  the  altitude  scaling  factor  (see  Chapter  V,  Section  A. 3). 

2.  Case  2  -  Locked  Onto  a  Target 

In  the  case  where  the  missile  is  locked  onto  a  target,  the  missile’s  new 
position  is  computed  as  follows.  A Di»t  is  computed  as  in  Equation  6.1.  Next  the 
missile’s  heading  is  computed  so  as  to  steer  it  directly  toward  the  target’s 
position: 

Dirtgt  =  aretan2(-[TZ  -  MZ],[TX  -  MX])  (6.5) 
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Where 


-  Dir^  it  the  direction  from  the  missile’s  position  to  the  target’s  position 

-  TX  is  the  X  coordinate  of  the  target’s  position 

-  TZ  is  the  Z  coordinate  of  the  target’s  position 

-  MX  is  the  X  coordinate  of  the  missile’s  position 

-  MZ  is  the  Z  coordinate  of  the  missile’s  position 


' 

-  oreton2(a,6)  is  a  function  which  returns  the  aretan 
0  to  211,  based  on  the  sign  of  a  and  6. 


in  the  range 


Once  Dir.,  is  known,  the  missile’s  new  X  and  Z  coordinates  can  be  calculated  as 


MX*,*  =  MXM  +  [cos(Dirtft)*ADi»t] 
MZn„  =  MZoU~\sin{Dirtft)*&Di8t] 


(6.6) 

(6.7) 


Next  the  missile’s  altitude  (MY)  is  adjusted  a  proportion  of  the  total  altitude 
difference  between  it  and  the  target,  based  on  the  ratio  of  A  Diet  to  the  total 
distance  (along  the  horizontal  plane)  to  the  target. 


Di»tift  =V(TX-MX)7  +  (TZ-MZ) 

A  Dirt 


-TY)* 


Diet 


tft 


(6.8) 

(6.9) 


Where 

-  Distlft  is  the  distance  to  the  target  measured  along  a  horizontal  plane. 

-  MY  and  TY  are  the  Y  (altitude)  coordinates  of  the  missile  and  target, 
respectively. 
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C.  DETERMINING  THE  LINE  OF  SIGHT 


Once  the  new  position  of  the  missile  hss  been  calculated,  the  next  step  in 
displaying  the  terrain  is  to  determine  another  point  along  the  camera’s  line  of 
sight:  the  look-at  position.  This  calculation  is  also  broken  into  two  cases  based 
on  whether  the  missile  is  or  is  not  locked  onto  a  target  (see  Figure  6.2). 

The  case  where  the  missile  is  locked  on  is  trivial,  the  look-at  position  is 
sunply  set  to  the  coordinates  of  the  locked-on  target. 


LX=TX 

(6.10) 

** 

ii 

H 

(6.11) 

£ 

ii 

N 

(6.12) 

Where  LX ,  LY ,  and  LZ  are  the  X,  F,  and  Z  coordinates  of  the  look-at  position. 
This  centers  the  target  in  the  displayed  three-dimensional  scene. 

When  the  missile  is  not  locked  onto  a  target,  the  camera’s  look-at  position  is 
a  function  of  the  missile’s  position,  the  missile’s  heading,  and  the  pan  and  tilt 
angles  of  the  camera.  It  is  determined  as  follows 


Dirio*k  =  H'od^+Pon 

(6.13) 

LX  =  MX  +  \co*(Dirlook)*Distloek} 

(6.14) 

LZ  =  MZ-[ain(Dirl09k)*  Distlook\ 

(6.15) 

LY  =  MY+\Di»tt9ok*t*n(Tilt)\ 

(6.16) 
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Case  1  -  Missile  Locked  on  a  Target. 
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Case  2  -  Missile  Not  Locked  on  Target 


Figure  6.2  Determining  the  Camera’s  Look-at  Position 


Where 


-  Dirlo0i  is  the  direction  the  camera  is  looking 

-  Pan  is  the  pan  angle  of  the  camera 

-  Tilt  is  the  tilt  angle  of  the  camera 

-  Di»tltok  is  an  arbitrary  distance  over  the  ground  that  the  camera  looks  ahead. 
Since  the  only  purpose  of  LX ,  L  Y,  and  LZ  is  to  determine  a  point  along  the 
camera’s  line  of  sight,  any  positive  number  will  be  acceptable.  A  value  of  five 
kilometers  is  currently  used. 


D.  DISPLAYING  THE  SCENE 

Once  a  line  of  sight  has  been  determined,  the  next  steps  are  to  apply  the 
appropriate  viewing  transformations,  draw  the  filled  polygons  that  make  up  the 
terrain,  and  add  other  items  to  the  scene  such  as  targets  and  roads. 

1.  Viewing  Transformations 

It  is  possible  to  project  a  three-dimensional  object  onto  a  two 
dimensional  viewing  surface  in  two  basic  ways.  In  one  method,  the  parallel 
projection  all  the  points  of  the  object  are  projected  along  parallel  lines.  This  has 
the  advantage  of  preserving  the  relative  dimensions  and  angles  within  an  object 
and  is  used  when  accurate  views  of  various  sides  of  an  object  are  needed  such  as 
in  architectural  drawings.  In  the  other  method,  the  perspective  projection,  all 
the  points  of  an  object  are  projected  along  lines  that  converge  at  a  single  point 
called  the  Center  of  Projection.  In  this  method,  relative  dimensions  are  not 
preserved.  Lines  closer  to  the  projection  plane  appear  larger  than  those  that  are 
more  distant.  The  perspective  projection  provides  a  view  of  three-dimensional 


The  perspective  projection  forms  a  view  frustum  as  shown  in  Figure  6.4. 
Any  object  within  the  frustum  between  the  near  and  far  clipping  planes  will  be 
displayed  in  the  scene.  Objects  outside  this  view  volume  are  clipped  and 


discarded. 

Next,  the  frustum  formed  by  the  perspective  projection  must  be 
positioned  along  the  camera’s  line  of  sight.  This  is  accomplished  by  another 
transformation  matrix  constructed  via  a  graphics  library  procedure  named  lookat . 
The  lookat  procedure  takes  the  following  inputs: 

-  Vz,  V  and  Vz:  the  X,  Y,  and  Z  coordinates  of  the  center  of  projection. 

-  Pt,  P  ,  and  Pz‘.  the  X,  Y,  and  Z  coordinates  of  the  look-at  position. 

-  Twist,  a  right  handed  rotation  of  the  scene  about  the  line  of  sight. 

The  transformation  matrix  formed  by  lookat  is  actually  the  result  of  multiplying 
four  other  transformation  matrices  [Ref.  7:p.  C-2] 


Lookat(Vx,Vf,Vt,Px,Py,Pz,Twi»t )  = 

Tran»{-Vx-  Vy,-  Vz)  xRotj)(0)x  Rot  x($)x  Rot  x(- Twist) 


Whtre.  Trans{-Vx-Vy-Vx)  = 
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Rott(9)  = 
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As  can  be  seen,  this  transformation  simply  translates  the  center  of  projection  to 
the  origin,  then  rotates  the  view  frustum  about  X  and  Y  axes  to  align  with  the 
line  of  sight.  Finally  the  twist  angle  is  added  with  a  rotation  about  the  Z  axis. 


In  the  flight  simulation,  the  twist  angle  is  analogous  to  the  “roll”  angle  of  an 
aircraft  or  missile.  A  value  of  zero  is  currently  used,  but  other  values  could  be 
used  if  the  roll  of  the  missile  during  flight  was  added  to  the  model. 

2.  Determining  Which  Polygons  to  Draw 

After  the  correct  viewing  transformations  have  been  applied,  the 
polygons  that  comprise  the  scene  must  be  drawn.  Although  the  IRIS  will  “clip” 
polygons  which  lie  outside  the  perspective  projection’s  view  volume,  an  increase  in 
frame  update  speed  can  be  achieved  by  not  attempting  to  draw  those  that 
obviously  lie  outside.  This  is  discussed  further  in  the  following  section  on 
simulator  performance. 

The  term  view -bound  is  used  to  describe  a  north-south  oriented 
bounding  box  around  those  parts  of  the  scene  that  are  sent  to  the  graphics 
pipeline.  The  view-bound  is  described  by  the  index  of  the  northernmost, 
southernmost,  easternmost,  and  westernmost  gridsquare  to  be  drawn.  It  is 
calculated  by  extending  (if  necessary)  the  line-of-sight  vector  until  it  intersects  the 
horizontal  plane  Y  -  Min  elev,  where  Min  elev  is  the  minimum  elevation  value 
of  the  terrain.  The  view -bound  is  calculated  as  being  20  gridsquares  to  the 
north,  south,  east,  and  west  of  this  intersection  point.  If  the  missile’s  X  and  Z 
coordinates  are  not  within  the  calculated  view  -  bound,  the  bounds  are  extended  to 
include  them.  Figure  6  5  illustrates  this  construction. 


Missile  Position  (MX,  MY,  MZ) 


North 

View-bound 


South 

View- 

bound 
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Look-at  Position  (LX,  LY,  LZ) 


West  X  Line  of  Sight 
View-bound  \ 


^Bounds  extended 
to  include  missile  nosition 


Horizontal  Plane:  Y  =  Min  elevation 


East  View- bound 


1)  Line  of  sight  vector  is  extended  down 

to  intersect  the  minimum  elevation  plane, 

2)  View  bound  extends  20  gridsquares  north, 
south,  east  and  west  of  the  intersection. 

3)  Bound  is  extended,  if  necessary  to 
include  the  missile’s  position. 


Figure  6.5  Construction  of  the  View-bound 


3.  Hidden  Surface  Removal 
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A  final  detail  that  must  be  taken  care  of  is  the  removal  of  hidden 
surfaces  from  the  scene.  A.  hidden  surface  is  simply  a  part  of  the  scene  that  is 
obscured  by  some  object  in  the  foreground,  such  as  a  valley  that  it  hidden  behind 
a  large  hill. 

The  IRIS  supports  a  method  in  hardware  called  Z- Buffering.  In  this 
method,  a  buffer  is  maintained  for  each  pixel  position  on  the  monitor  and 
contains  the  “depth”  (transformed  Z  coordinate)  of  the  part  of  the  scene  that 
generated  that  pixel.  Before  drawing  is  started,  the  buffer  is  initialized  to  the 
maximum  depth  value  (the  value  of  the  far  clipping  plane)  for  each  pixel  position. 
Before  each  new  pixel  is  drawn,  its  depth  is  compared  to  the  depth  stored  in  the 
buffer.  If  its  depth  is  greater  than  the  stored  depth  it  is  not  drawn.  If  it  is  less 
than  the  stored  depth,  it  is  drawn  and  its  depth  value  replaces  the  value  in  the 
buffer.  This  method  could  not  be  used  in  the  project  for  two  reasons.  First,  with 
comparisons  having  to  be  made  on  a  pixel-by-pixel  basis,  it  slows  down  the  frame 
update  rate  to  an  unacceptable  level.  Second,  the  IRIS  does  not  allow  the  use  of 
Z-buffering  and  double- buffering  at  the  same  time.  Double-buffering  is  necessary 
to  implement  the  animation  of  the  scenes. 

Another  common  method  of  hidden  surface  removal  is  the  painter’s 
algorithm.  It  derives  its  name  from  the  way  a  painter  would  draw  a  scene  on 
canvas,  drawing  in  all  the  background  and  then  adding  foreground  objects  by 
painting  over  the  background  objects  they  obscure.  Implementing  this  algorithm 


in  computer  graphics  means  drawing  the  scene  in  an  ordered  fashion,  such  that 
the  most  distant  objects  from  the  viewer  are  drawn  first  and  those  closest  to  the 
viewer  are  drawn  last.  Since  the  gridsquares  comprising  the  terrain  form  well 
defined  rows  and  columns,  an  efficient  implementation  of  this  algorithm  is 
possible.  That  implementation  is  described  below. 

The  implementation  can  be  thought  of  on  a  conceptual  level  as  follows. 
A  line,  perpendicular  to  the  line-of-sight,  is  constructed  to  serve  as  a  pseudo¬ 
scanline.  Gridsquares  within  the  view-bound  are  drawn  as  they  are  intersected  by 
this  scanline.  The  scanline  is  first  positioned  along  the  line-of-sight  vector  so  that 
it  intersects  the  far  corner  gridsquare  of  the  view- bound.  After  all  the  gridsquares 
along  the  scanline  have  been  drawn,  it  is  moved  one  gridsquare  closer  to  the  view 
position,  along  the  line-of-sight  vector,  and  the  process  is  repeated.  This 
continues  until  all  the  gridsquares  within  the  view-bound  have  been  drawn. 
Figure  6.6  illustrates  this  process. 

From  Figure  6.6,  notice  that  each  scanline  passes  through  three 
gridsquares  in  a  column,  shifts  over  a  column,  then  passes  through  three 
gridsquares  in  the  next  column.  The  number  of  gridsquares  drawn  in  a  column 
(or  row)  before  advancing  to  the  next  column  (or  row)  can  be  determined  by 
computing  the  tangent  of  the  scanline’s  direction.  If  the  magnitude  of  the 
tangent  is  greater  than  1.0,  scanlines  will  run  and  shift  along  columns  of 
gridsquares.  If  it  is  less  than  1.0,  scanlines  will  run  and  shift  along  rows  of 
gridsquares.  The  term  threshold  is  used  in  the  remainder  of  the  algorithm  to 
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describe  the  number  of  gridsquares  drawn  before  a  shift  of  column  (or  row)  takes 
place.  It  is  computed  as 


threshold  — 


nearest  integer 
nearest  integer 


tan (£>«>(an)  ,  if  tan(Dir,cw|)|  >1.0 
(tan(Dt>ieflB))_1|  ,  if  |tan(D»>w-n)|<1.0 


(6.25) 


The  pseudocode  for  implementing  the  algorithm  is  shown  in  Figure  6.7. 
The  case  shown  is  for  a  line-of-sight  direction  that  is  in  the  first  octant  (between 

n 

0  and  —  radians).  The  algorithm  for  the  other  seven  octants  is  similar,  the 
4 

difference  being  the  direction  the  scan  line  advances,  and  the  direction  it  shifts 
when  the  threshold  is  reached.  Table  6.1  summarizes  these  parameters  for  all 
eight  octants. 

TABLE  6.1  VARYING  PARAMETERS  FOR  THE  SCANLINE  ALGORITHM 
BASED  ON  THE  OCTANT  OF  THE  LOOK  DIRECTION 


Octant 

Look  Directions 

[  Scan  Line  Advances 

When  Threshold  is  Reached 

From 

To 

From 

To 

1 

KB 

North 

South 

Shift  one  column  East 

2 

n/4 

n/2 

East 

West 

Shift  one  row  North 

3 

n/2 

m/2 

West 

East 

Shift  one  row  North 

4 

3n/2 

n 

North 

South 

Shift  one  column  West 

5 

n 

m/4 

South 

North 

Shift  one  column  West 

6 

5TI/4 

m/2 

West 

East 

Shift  one  row  South 

mm 

3n/2 

7n/4 

East 

West 

Shift  one  row  South 

■» 

7TI/4 

2n 

South 

North 

Shift  one  column  East 

Notice  the  step  draw  gridsquare[z_indexj[x  indexj  in  the  algorithm. 
Since  a  gridsquare  contains  terrain,  and  can  also  contain  roads  and  targets,  an 
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C*ku!ate  the  threshold  value 


coant  *-  0 

start  x  index  <-  west  view  bound 
start  j,  index  *-  north  _view_bonnd 

While  start _s_index  >  south  viewbound  do 
sindex  +-  start  _s_index 
xicdex  *-  start_x_index 

while  (x  index  5;  east  view  bound)  and  (s  index  ^  south  view  bound)  do 

{  traverse  a  scanline  } 
draw  gridsquare(s_index][x_indexj 
i  index  s  index  -  1  {move  it  one  gridsquare  south} 
count  «-  count  +  1 

if  count  =  threshold  then 

x  index  xindex  +  I  {move  it  one  grid  square  east} 
count  ♦-  0  {  reset  count} 

end  if 

end  while 

(move  on  to  next  scanline:  start  it  one  gridaquare  to  the  west} 
start  x  *-  start  _x  -  1 
count  0 

if  (start  x  <  w eat _view  bound)  then 
start  x  west  view  bound 

start  s  start  s  -  threshold 

endif 

endwhile 


Figure  6.7  Pseudocode  for  the  First  Octant  Sc&nline  Algorithm 


ordering  of  these  parts  of  the  gridsquare  must  also  take  place.  The  two  triangles 
forming  the  terrain  are  drawn  first,  next  any  roads  are  drawn,  and  finally  any 
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targets  are  drawn.  The  details  of  integrating  the  targets  and  roads  into  the  scene 
are  covered  in  the  following  two  chapters. 


The  resulting  scene  is  shown  in  Figure  6.8,  a  photograph  of  the  IRIS 
monitor  during  the  flight  simulation.  Note  how  the  hidden  surface  removal  allows 
the  foreground  hills  to  naturally  obscure  the  valleys  behind  them.  Also  note  the 
effect  of  the  lighting  model  and  texturing  described  in  Chapter  V. 


E.  SIMULATOR  PERFORMANCE 

Data  collected  while  running  the  simulator  shows  that  the  average  frame 
update  rate  is  approximately  four  frames  per  second.  The  Unix  profile  utility 
was  used  to  determine  which  procedures  accounted  for  the  majority  of  the 


simulator '8  time  usage.  Table  6.2  shows  the  results  for  the  top  four  routines. 
TABLE  6.2  FOG-M  ROUTINES  USING  THE  MOST  CPU  TIME 


%  CPU  Time 

Routine  Name 

Purpose 

16.9 

polf 

Iris  graphics  library  filled  polygon  routine. 

13.7 

display  terrain 

Output  3-D  scene  with  hidden  surface  removal. 

8.7 

malloc 

C  language  built  in  routine  for  dynamic 
memory  allocation. 

4.5 

gl  findhash 

Low  level  Iris  graphics  library  routine,  used  for 
the  hash  tables  associated  with  graphical 
objects  (Not  user  accessible). 

The  top  two  entries  in  Table  6.2  are  directly  involved  with  outputting  polygons  to 
build  the  terrain  image  It  is  therefore  reasonable  to  believe  that  the  frame 
update  rate  depends  heavily  on  the  number  of  polygons  that  are  passed  to  the 


geometry  engines. 
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Figure  6.0  is  a  sc&tterplot  showing  the  frame  update  speed  achieved  when 
various  numbers  of  polygons  were  attempted  to  be  drawn.  The  data  was 
generated  by  reading  the  system  clock  before  each  frame  update  and  calculating 
the  number  of  polygons  based  on  the  view -bound  that  was  used  during  that 
frame.  The  graph  clearly  shows  the  effect  the  view-bound  has  on  the  frame 
update  rate.  The  next  two  entries,  malloc  and  gl  findhash,  are  traceable  to  the 
making  and  deleting  of  the  graphical  objects  that  store  the  targets  (this  process  is 
explained  in  Chapter  VII).  As  an  experiment,  the  construction  and  deletion  of 
the  targets’  objects  was  removed  from  the  simulation  and  the  targets  were  simply 
displayed  in  stationary  positions.  The  profile  results  from  the  simulator  run  in 
this  configuration  is  shown  in  Table  6.3.  Figure  6.10  is  another  scatterplot, 
generated  in  the  same  manner  as  Figure  6.9,  except  that  the  simulator  was  run  in 
the  stationary  target  configuration.  Eliminating  the  dynamic  memory 
management  associated  with  the  target’s  graphical  objects  increased  the  average 
frame  update  rate  from  2.99  to  3.90  frames  per  second.  Also,  the  maximum  frame 
update  rate  achieved  doubled  from  7.5  to  15.0  frames  per  second.  This  would 
suggest  that  an  area  for  further  research  is  an  improved  algorithm  for  target 
updating  that  does  not  involve  dynamically  allocating  memory. 

The  fact  that  the  frame  update  rate  is  so  heavily  dependent  on  the  number  of 
polygons  passed  to  the  geometry  engine  suggests  that  a  more  sophisticated 
method  of  determining  the  view-bound  may  pay  off  in  increased  performance. 
For  example,  the  present  method  does  not  take  into  account  the  field  of  view 
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Figure  6.9  Display  Update  Rate  vs  Number  of  Polygons 


angle.  It  should  be  possible  to  bound  the  line-of-sight  intersection  point  with  less 
than  twenty  grid  squares  when  the  field  of  view  angle  is  small.  However,  tuny  new 
algorithm  developed  can  not  be  so  sophisticated  that  it  negates  the  performance 
increase  by  requiring  intensive  computations. 


TABLE  6.3  FOG-M  ROUTINES  USING  THE  MOST  CPU  TIME 
(WITH  STATIONARY  TARGETS) 


%  CPU  Time 

Routine  Name 

Purpose 

23.9 

polf 

Iris  graphics  library  filled  polygon  routine. 

22.3 

display  terrain 

Output  3-D  scene  with  hidden  surface  removal. 

5.5 

color 

Iris  graphics  library  routine  which  sets  the 
current  drawing  color. 

4.1 

line  intersect2 

Finds  the  intersection  point  of  two  lines.  This 
routine  is  used  exclusively  during  the  road 
building  process  and  therefore  is  not  used  at 
all  in  the  display  loop. 

4.0 

poly 

. 

Iris  graphics  library  unfilled  polygon  routine. 
Used  during  the  display  loop  to  outline  the 
road  segments. 

VII.  TARGET  INTEGRATION 


A.  GENERAL 
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The  primary  targets  of  a  FOG-M  missile  are  tanks,  helicopters,  and 
reinforced  ground  installations.  The  simulator  is  designed  to  handle  many  types 
of  targets,  including  various  tanks  and  helicopters,  but  only  a  single  type  of  tank 
is  currently  implemented.  The  prototype  simulator  provides  an  Ethernet 
networking  capability  to  allow  the  input  of  actual  target  positions  in  real-time. 
This  simulates  the  input  that  would  be  received  by  a  production  simulator  during 
computerized  mock  combat  field  experiments.  In  its  networking  mode,  the 
simulator  receives  target  position  and  orienti  *.ion  data  from  an  interactive 
program  running  on  a  different  IRIS  workstation.  The  target  program,  still  in 
testing  and  not  detailed  in  this  study,  provides  the  capability  to  dynamically 
insert  and  delete  targets  at  any  location,  and  to  modify  their  speed  and  direction. 
In  the  simulator’s  stand-alone  mode,  there  are  ten  tanks  defined  by  default  that 
criss-cross  the  ten  kilometer  square  terrain  area.  These  tank  targets  move  at  a 
constant  speed  of  fifteen  knots  and  reverse  direction  when  they  reach  one  of  the 
edges  of  the  ten  kilometer  terrain  square.  No  automated  path  planning  is 
presently  performed  in  either  mode,  so  the  tanks  blithely  traverse  even  the 


steepest  terrain.  The  default  targets  minimize  this  problem  by  traveling  the  length 
of  the  valleys  for  the  most  part. 

B.  TARGET  CREATION 

Target  creation  is  simplified  through  the  use  of  graphical  objects.  The  actual 
image  of  a  tank  is  defined  initially  by  the  tedious  specification  of  the  three 
coordinates  of  each  vertex  of  each  of  the  polygons  that  comprise  the  tank  (Figure 
7.1).  Using  objects,  this  need  only  be  done  once,  placed  in  an  object,  and  then 
referred  to  by  a  single  name  within  each  target  object.  Thus  each  target  is 
described  by  an  object  (the  tank  object)  within  another  object  (the  target  object). 
In  addition  to  the  tank  object,  the  target  object  also  contains  the  transformation 
commands  that  move  the  tank  from  the  origin  to  its  location  on  the  terrain  (a 
translation ),  and  face  it  in  the  direction  it  is  moving  (a  rotation). 

1 .  The  Systen  1  Matrix 

The  rotation  and  translation  commands  work  by  modifying  the  sgstem 
matrix.  The  system  matrix  is  a  global  data  structure  that  is  used  to  transform 
coordinates  from  the  three-dimensional  world  space  into  the  two-dimensional 
screen  space.  Each  transformation  can  be  performed  as  a  series  of  computations 
on  individual  X,Y.  and  Z  coordinates,  but  the  transformations  can  also  be 
accomplished  with  a  single  matrix  multiplication.  The  IRIS  has  a  matrix 
multiplier  built  into  its  hardware,  so  matrix  operations  are  very  efficient.  At  least 
three  transformations  must  be  applied  to  every  endpoint  on  the  tank:  a  coordinate 
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Figure  7.1  Simulator  Scenes 


scaling,  a  translation,  and  a  rotation.  Rather  than  do  three  separate  matrix 
multiplications,  the  three  transformation  matrices  can  be  combined,  so  that  all  of 
the  transformations  are  accomplished  in  a  single  matrix  multiplication.  The 
matrices  are  combined  by  applying  each  of  them  to  the  system  matrix.  Each 
point  is  now  completely  transformed  through  a  single  multiplication  with  the 
system  matrix.  When  a  new  transformation  is  needed,  the  system  matrix  must  be 
reset  by  applying  the  inverses  of  the  old  transformations,  or  by  copying  the 
original  contents  back  into  the  system  matrix.  Two  commands  are  provided  with 
the  IRIS  to  support  the  latter  method.  Pushmatriz  takes  a  copy  of  the  system 
matrix’s  current  contents  and  saves  it  on  the  system  stack.  After  the 
transformations  have  been  applied,  and  the  drawing  that  used  those 
transformations  has  been  completed,  the  system  matrix  is  reset  by  calling 
popmatriz ,  which  retrieves  the  copy  placed  on  the  stack  by  pushmatrix  and 
restores  the  contents  of  the  system  matrix  to  the  previously  saved  values. 

2.  Target  Transformations 

The  tank  is  initially  defined  with  its  center  interior  at  the  origin 
(coordinates  (0,0,0)).  While  it  is  not  important  which  point  on  or  in  the  tank  is 
placed  at  the  origin,  it  is  crucial  that  the  tank  be  defined  somewhere  around  the 
origin  in  order  for  the  rotation  command  to  have  the  desired  effect.  The  original 
direction  of  the  tank  is  significant  only  to  the  extent  that  it  must  be  known  in 
order  to  calculate  the  appropriate  rotation  to  achieve  a  specified  heading.  The 

tank  in  FOG-M  faces  to  the  right  (zero  radians  mathematically,  or  a  compass 
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heading  of  ninety  degrees)  initially.  During  target  creation,  dummy  (zero  valued) 
rotation  and  translation  commands  are  placed  in  the  target  object,  to  be  updated 
for  display  by  a  later  editing  of  the  object.  Since  all  rotation  and  translation 
commands  affect  the  system  matrix  (as  previously  described)  and  are  cumulative, 
each  target  object  must  apply  its  transformations,  be  drawn,  and  then  remove 
those  transformations  so  that  latter  drawing  commands  are  not  distorted.  Within 
each  target  object,  the  contents  of  the  system  matrix  are  saved  with  a  pushmatrix 
call,  the  appropriate  rotation  and  translation  commands  are  applied  to  the  system 
matrix  (in  reverse  order,  due  to  the  nature  of  matrix  multiplication),  the  target  is 
drawn  by  calling  the  tank  object,  and  then  popmatrix  is  called  to  reset  the  system 
matrix. 

C.  ANIMATION 

Animation  of  the  targets  is  accomplished  using  the  objects  and 
transformations  described  above.  The  targets  must  be  moved  slightly  before 
being  redrawn  in  the  next  frame.  This  requires  new  (X,Y,Z)  coordinates,  from  the 
network  or  from  local  calculations.  Then  a  global  data  structure  is  updated  to 
indicate  when  in  the  display  algorithm  the  target  should  be  drawn,  and  the 
translation  command  in  the  target  object  is  edited  to  provide  the  new  coordinates. 
As  each  frame  is  displayed,  targets  appear  in  slightly  shifted  positions,  and  give 
the  appearance  of  animated  motion. 
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The  calculation  of  new  coordinates  requires  the  maintenance  of  position, 
speed,  and  direction  data  for  each  target.  The  total  distance  traveled  between 
screen  updates  is  the  product  of  the  elapsed  time  (obtained  from  the  IRIS’s  real¬ 
time  clock)  and  the  target’s  speed,  scaled  so  the  units  match.  In  the  networking 
version  of  the  simulator  this  is  done  remotely;  in  the  stand-alone  version 
everything  must  be  maintained  locally.  The  target’s  direction  of  travel  is  stored 
in  radians,  and  is  measured  using  the  standard  mathematical  convention  as 
opposed  to  a  compass  heading  (Figure  7.2).  This  allows  calculation  of  the  the 
appropriate  east /west  (A  A”)  and  north/south  (A Z)  movement  as  follows: 

AX  =  cos  (direction)  *  time  *  speed  *  scale  factor  (7.1) 

A  Z~  Bin(dircction)  *  time  *  speed  *  scale  factor  (7.2) 

The  new  target  ( X,Z )  position  is  the  sum  of  the  old  position  and  the  offsets 
(AA,AZ)  from  Equations  7.1  and  7.2.  Since  all  of  the  current  targets  are  tanks, 
their  }'  coordinates  (altitude)  should  be  taken  from  the  height  of  the  terrain 
underneath  the  tank.  This  is  obtained  from  the  DTED  interpolation  routine 
grid  level,  which  is  called  with  the  new  ( X,Z )  coordinates  as  input  parameters. 

D  DISPLAY 

Chapter  Five  explained  the  exploitation  of  the  structure  of  the  data  and  the 
use  of  the  painter’s  algorithm  to  solve  the  polygon  ordering  problem  without 
resorting  to  slower  or  more  complicated  schemes  like  Z-buffering  or  Binary  Space 
Partitioning  'Ref.  13|.  Targets  cannot  merely  be  drawn  after  the  terrain  because 
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Figure  7.2  Direction  Conventions 


of  the  same  ordering  problem.  Otherwise,  targets  appear  in  front  of  everything, 
and  it  is  impossible  to  simulate  a  target  moving  out  of  sight  into  the  distance  or 
behind  some  terrain  feature.  The  implementation  of  the  target  display  algorithm 
is  greatly  facilitated  by  the  use  of  objects.  Objects  allow  the  grouping  of  drawing 
commands  into  a  subroutine- like  package,  which  can  be  edited  (effectively 
allowing  parameterization)  and  then  displayed  with  a  single  command  A  two- 
dimensional  array  of  object  “names”  (the  object  namt  array)  is  initialized  so 
each  element  of  the  array  represents  the  target  object  to  be  drawn  in  the  one 
hundred  rneter  square  of  terrain  with  the  same  indices.  Since  the  C  programming 
language  recognizes  the  value  integer  zero  as  FALSE,  and  anything  else  as  TRUE, 
this  array  does  double  duty  as  an  array  of  booleans  indicating  the  presence  or 
absence  of  a  target  object  in  a  particular  one  hundred  meter  grid  square  (No 
target  objects  are  given  the  “name”  zero,  which  would  indicate  FALSE.)  A  list  of 
targets  is  used  to  reset  this  array  to  all  zeroes  before  each  screen  update  (i.e  only 
those  elements  that  contained  targets  need  to  be  zeroed)  so  maintenance  overhead 
of  the  array  is  minimized.  The  new  target  positions  are  received  over  the 
network,  or  are  calculated,  based  on  each  target’s  ja>sition,  speed,  and  direction, 
plus  the  elapsed  real-time  since  the  last  update.  The  appropriate  object- name- 
array  indices  are  calculated  from  the  new  target  position  and  the  object -name- 
array  is  updated  If  this  is  the  first  (or  only)  target  in  the  designated  one  hundred 
rneter  grid  square,  the  update  is  accomplished  by  making  a  new  object,  and 
setting  the  object-name-array  element  equal  to  the  new  object’s  integer  '  name 


If  the  array  shows  that  some  other  target  is  already  in  that  particular  piece  of 
terrain  (i.e.  the  object-name-array  element  is  non-zero),  the  current  target  is  just 
added  to  the  object  specified  by  the  “name”  in  the  array.  Once  this  has  been 
done  for  each  target,  this  array  is  available  for  the  display terrain  module. 
Display  terrain  checks  the  array  as  it  draws  each  square  of  the  terrain  to  see  if 
any  targets  should  be  drawn.  If  so,  it  calls  the  indicated  target  object  just  after  it 
has  drawn  the  one  hundred  meter  grid  square  on  which  the  target(s)  rests.  Note 
that  this  causes  the  target(s)  to  be  drawn  at  the  correct  time  for  the  painter's 
algorithm.  The  correct  place  to  draw  the  target  still  mu6t  be  specified  by  the 
transformation  commands  within  the  target  object. 

In  some  cases  it  is  necessary  to  draw  a  target  more  than  once.  Targets  that 
straddle  a  one  hundred  meter  grid  square  boundary  must  be  drawn  on  top  of  both 
(or  possibly  all  four)  grid  squares  in  order  to  avoid  being  partially  obscured  by 
whichever  grid  square  is  drawn  last.  (The  target  must  be  drawn  immediately  after 
the  grid  square  on  which  it  rests  to  ensure  that  the  target  will  be  obscured  when 
it  should  be,  by  terrain  drawn  in  the  foreground.)  Since  the  calculation  of 
boundary  intersection  involves  several  trigonometric  functions  and  an  allowance 
for  the  distance  between  the  center  of  the  tank  and  its  boundaries  (which  varies 
with  the  direction  of  the  tank),  a  simplifying  algorithm  is  used.  If  the  tank  is  close 
enough  to  a  boundary  that  the  most  distant  part  of  the  tank  might  cross  the 
boundary  (see  tanks  A  and  B  in  Figure  7  3),  the  target  object  is  also  drawn  after 
the  adjoining  grid  square(s). 
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Figure  73  Boundary  Conditions 


The  one  hundred  meter  grid  square  is  essentially  divided  into  three  areas: 
the  middle,  its  sides,  and  its  corners.  In  the  middle,  the  tank  cannot  overlap  any 
other  grid  square.  On  the  sides,  the  tank  may  overlap  one  adjoining  grid  square, 
and  in  the  corners,  the  tank  may  overlap  three  adjoining  grid  squares.  The 
reference  point  on  the  tank  (the  position  the  X,  Y,  and  1  coordinates  refer  to)  is 
located  at  the  very  center  of  the  tank.  The  tank  is  thirty  feet  long,  so  the  most 
distant  parts  of  the  tank  are  within  a  fifteen  foot  radius  of  the  tank’s  reference 
point.  The  lines  that  mark  the  side  and  corner  areas  are  thus  fifteen  feet  inside  the 
borders  of  the  grid  square.  Once  the  tank's  reference  point  is  within  these  areas, 
it  is  potentially  obscured  by  the  later  drawing  of  the  adjacent  grid  square(s)  It 
might  not  be  obscured  if  it  is  paralleling  a  side,  for  example,  but  the  overhead  of 
drawing  it  twice  (or  even  four  times)  when  it  does  not  need  to  be  is  smaller  than 
the  overhead  of  the  calculations  to  determine  if  the  position  and  direction  of  the 
tank  have  it  actually  crossing  one  or  more  edges 

The  repeated  drawing  is  accomplished  by  adding  a  “new"  target  to  the  array 
of  target  objects.  The  "new”  target  object  is  drawn  at  the  exact  same  location  in 
the  three-dimensional  terrain,  but  it  is  drawn  after  a  different  one  hundred  nicer 
grid  square,  so  it  will  have  different  target  object  array  indices,  and  be  in  a 
separate  target  object,  even  though  the  two  (or  four)  targets  drawn  will  overwrite 
each  other  and  produce  a  single  image 


VIII  (  ULTURAL FEATURE  INTEGR  ATION 


The  addition  of  cu  tura)  features  add  much  to  the  reaiisnj  of  the  displayed 
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Figure  8.1  shows  a  segment  of  the  file  containing  data  for  two  roads  along 
with  a  diagram  showing  their  locations  within  the  terrain.  Each  road  entry  is 
composed  of  three  parts  The  first  part  is  the  width  of  the  road  in  feet.  Next  is 
an  integer  N,  where  N  is  the  number  of  data  points  used  to  digitize  the  road. 
Third  is  a  set  N  coordinate  pairs,  where  each  pair  represents  the  location  of  a 
digit  lied  point  along  the  road’s  centerline.  The  first  coordinate  of  the  pair  is  the 
east-west  location  of  the  point.  It  is  measured  in  feet  from  the  western  terrain 
Windary.  The  second  coordinate  of  the  pair  is  the  north-south  location  of  the 
point,  measured  in  feet  from  the  southern  terrain  boundary.  All  the  data  is  stored 
as  ASCII  text,  which  facilitates  editing  of  the  data  using  any  text  editor.  The 
DF.AD  data  file  also  contains  road  width  information  (in  meters)  and  stores  roads 
as  a  series  of  digitized  points.  The  major  difference  is  that  DFAD’s  points  are 
stored  as  latitudes  and  longitudes,  which  need  to  be  converted  before  they  can  be 
used  in  the  simulation.  Ref.  9] 


B  CONSTRUCTION  OF  THE  ROAD  POLYGONS 

Knowing  the  width  and  centerline  locations  for  the  road,  the  next  step  is  to 
construct  the  polygons  which  represent  it.  Although,  this  seems  like  a  simple 
procedure  t  is  complicated  by  the  fact  that  the  road  must  follow  the  rise  and  fall 
>f  the  terrain  Also,  in  order  for  hidden  surface  elimination  to  occur,  the  road 
must  t*  divided  at  th<  gridsquare  boundaries  so  that  each  piece  can  be  drawn 
along  with  its  corresponding  gridsquare.  The  result  is  that  the  road  must  be 
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broken  into  many  planar  polygons,  where  each  polygon  is  a  portion  of  the  road 
that  overlays  one  of  the  terrain  triangles  within  a  gridsquare.  Figure  8.2 
illustrates  this  division  and  defines  some  of  the  terms  used  in  the  description  that 
follows.  The  high  level  pseudocode  for  processing  the  road  data  and  constructing 
the  planar  polygons  is  shown  in  Figure  8.3.  As  the  pseudocode  shows,  each  road 
is  processed  a  segment  at  a  time.  For  each  segment 

-  The  end  points  of  the  segment’s  left  and  right  side  are  calculated.  A  look¬ 
ahead  to  the  next  road  segment  is  done,  allowing  the  ends  of  adjacent 
segments  to  be  calculated  so  that  they  meet  cleanly. 

-  A  bounding  box,  which  contains  all  the  gridsquares  intersected  by  the 
segment,  is  constructed. 

Next,  for  each  gridsquare  in  the  bounding  box,  the  road  segment  is  divided  into 
the  road-poiygons  at  the  gridtriangle  boundaries.  Note  that  all  the  vertices  of  the 
road-polygons  fall  into  one  of  five  types: 

-  The  intersection  of  a  segment’s  left  side  with  the  side  of  a  gridtriangle. 

-  The  intersection  of  a  segment’s  right  side  with  the  side  of  a  gridtriangle. 

-  A  gridsquare’s  comerpoint  that  is  contained  within  the  road  segment. 

-  An  endpoint  of  the  left  side  of  the  road. 

-  An  endpoint  of  the  right,  side  of  the  road. 

The  road  polygon  is  constructed  by  finding  all  the  above  vertices  which  exist,  and 
ordering  them  counterclockwise.  The  counterclockwise  ordering  is  necessary  for 
backface  polygon  removal  to  take  place.  The  intersections  only  define  the  X  and 
Z  coordinates  or  the  vertices.  The  Y  (elevation)  coordinate  is  found  by 
interpolating  between  the  terrain’s  elevation  at  the  three  corners  of  the 


corresponding  gridtriangle. 
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Figure  8.2  Constructing  the  Road  Polygons 
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While  more  data  in  the  road  data  file  do 
read  width_of_road 
read  numberofpoints 

read  segment’s  start  coordinate  pair  (seg  _*  tart) 
read  segment’s  end  coordinate  pair  (seg  end) 

for  i  =  3  to  number_of_points  ■+  1  do 

if  i  ^  number_of_points  then 

read  the  next  segment’s  end  coordinate  pair  (next  seg  end) 
else 

next  seg  end  _x  «-  seg  end  _x 
next  seg  end  s  «-  seg  end  * 
endif 

calculate  the  start  and  end  points  for  the  segment’s  left  and  right  side 
(left  start,  left  end,  rightstart,  right_end) 

calculate  a  bounding  box  around  the  road  segment 

for  each  gridsquare  within  the  bounding  box  do 

Construct  the  polygon  which  overlays  the  gridsquare’s  northern  triangle 
Add  the  polygon  to  the  road  object  associated  with  this  gridsquare 

Construct  the  polygon  which  overlays  the  gridsquare’s  southern  triangle 
Add  the  polygon  to  the  road  object  associated  with  this  gridsquare 
right  start  *-  right  end 

endwhile 

Figure  8.3  Pseudocode  for  Constructing  Road  Polygons 


C.  INTERNAL  ROAD-POLYGON  STORAGE 

A  global,  two-dimensional  array  of  graphiealobjtcts,  named  road ,  is  used  to 
store  the  road  polygons.  Each  entry  in  the  array  corresponds  to  the  pieces  of  road 
that  lie  within  a  gridsquare.  An  object  is  created  when  the  first  road-polygon  is 
constructed  for  a  gridsquare,  with  subsequent  road-polygons  being  inserted  into 
the  already  existing  object.  Since  the  roads  are  static  in  nature,  the  use  of  objects 


A' 


does  not  present  the  dynamic  memory  allocation  problems  associated  with  their 
use  in  storing  targets  (see  the  Simulator  Performance  Section  of  Chapter  VI).  A6 
each  gridsquare  of  the  terrain  is  drawn,  a  check  is  made  to  see  if  a  road  object 
exists  for  that  square.  If  one  does  exist,  the  associated  road-polygons  are  drawn 
immediately  after  the  terrain.  This  insures  that  hidden  surface  elimination  occurs 
for  the  roads  as  well  as  the  terrain.  A  photograph  of  terrain  which  includes  some 
sections  of  roads  can  be  seen  in  Chapter  VII,  Figure  7.1). 
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DC.  FOG-M  SIMULATOR  USER’S  GUIDE 


A.  OVERVIEW 

This  section  of  the  report  is  a  user’s  guide  to  running  the  FOG-M  simulator. 
The  simulator  was  built  to  be  largely  self  documenting.  Instructions  are  clearly 
displayed  on  the  screen,  including  diagrams  which  serve  as  a  reminder  of  the 
functions  of  the  various  controls.  A  knowledge  of  the  logon  procedure  for  the 
IRIS  workstation  and  the  basic  commands  of  the  UNIX  operating  system  is 
assumed. 

B.  STARTING  THE  SIMULATION 

To  start  the  simulation,  logon  to  the  IRIS  workstation  and  use  the  UNIX  cd 
command  to  change  to  the  directory  containing  the  simulation.  Currently  the 
simulation  is  in  the  directory  /work/terrain.  Therefore  issue  the  command: 

cd  /work/terrain 

Next,  start  execution  of  the  simulation  by  typing  the  command  fogm.  A 
welcome  screen  will  appear  on  the  display  as  shown  in  Figure  0.1.  Pressing  all 
three  of  the  mouse  buttons  simultaneously  will  stop  the  program  and  return 
to  the  UNIX  command  level.  This  option  of  pressing  all  three  buttons  to  exit  is 
available  at  any  time  during  the  execution  of  the  program.  Pressing  the  middle 


mouse  button  advances  the  display  to  the  next  screen  of  instructions.  When  the 


user  has  advanced  through  the  welcome  screen  and  the  two  instruction  screens 
(Figures  9.2  and  9.3)  he  is  presented  with  a  display  showing  a  two-dimensional 
contour  map.  This  is  the  prepunch  phase  of  the  simulation. 

C.  PRELAUNCH  CONTROLS 

The  purpose,  of  the  prelaunch  phase  is  to  allow  the  user  to  designate  a  missile 
launch  position  and  a  suspected  target  location  position.  In  effect,  the  user 
describes  an  initial  flight  path  for  the  missile. 

1.  The  Prelaunch  Display 

The  prelaunch  display  is  divided  into  three  sections  as  shown  in  Figure 
9.4.  The  upper  right  corner  of  the  display  contains  an  instruction  box  which 
summarizes  the  functions  of  the  mouse  buttons  for  this  phase.  The  lower  right 
corner  contains  a  prelaunch  statistics  box.  The  meanings  of  the  various  items 
within  the  statistics  box  are  explained  below.  The  majority  of  the  display  is 
occupied  by  a  two-dimensional  contour  map.  Each  of  the  square  grids  on  the 
contour  map  represents  a  one  square  kilometer  area.  The  colors  on  the  map  can 
be  interpreted  as  follows.  Green  areas  indicate  terrain  that  is  covered  with 
vegetation  that  is  greater  than  one  meter  high.  Brown  areas  indicate  terrain 
where  the  vegetation  is  less  than  one  meter  high.  Within  each  of  the  color 
categories,  the  elevation  of  the  terrain  is  indicated  by  the  intensity  of  the  color, 
with  the  brighter  colors  representing  the  higher  elevations. 
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Figure  64  The  Prelaunch  Display 


2  Selecting  the  Launch  Position 

The  launch  position  must  be  selected  first  To  select  the  launch  position, 
use  the  mouse  to  move  the  red  arrow  cursor  to  the  desi-ed  location  on  the  contour 
map  As  the  cursor  is  moved,  the  UTM  coordinates  of  the  current  cursor  location 
are  shown  in  the  Launch  Position  field  of  the  statistics  box  These  coordinates 
can  be  used  when  a  more  accurate  selection  of  the  launch  position  is  required  than 
is  obtainable  from  the  contour  map  alone  When  the  cursor  is  in  the  desired 
position,  press  the  left  mouse  button  to  lock  in  that  position  A  blue  circle  wnl 
appear  on  the  contour  map  showing  the  position  selected  and  the  workstation  will 
“beep,’’  confirming  the  selection  The  launch  position  ran  be  changed  any  time 
before  the  launching  of  the  missile  by  simply  moving  to  the  new  desired  location 
and  pressing  the  left  mouse  button. 

3  Selecting  the  Target  Position 

The  target  position  can  only  be  selected  after  a  launch  position  has  been 
set.  After  the  launch  position  has  been  selected,  moving  the  cursor  over  the 
contour  map  produces  the  following  effects: 

-  The  UTM  coordinates  of  the  current  cursor  position  are  shown  in  the  Target 
Location  field  of  the  statistics  box. 

-  A  “rubber  band”  line  is  drawn  on  the  contour  map  from  the  launch  position 
to  the  current  cursor  location.  This  line  represents  the  flight  path  the  missile 
would  take  if  the  current  cursor  position  was  selected  as  the  target  location. 

-  The  direction  and  length  of  the  flight  path  represented  by  the  above  line  are 
displayed  in  the  statistics  box  in  the  Heading  and  Distance  fields  respectively. 

Once  the  cursor  is  at  the  desired  target  location,  press  the  right  mouse  button 
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».  <  tirst  launch  >f  any  execution  Subsequent  launches  proceed  with  no 

k.  1)  .ring  this  delay  a  countdown  will  appear  in  the  bottom  of  the  statistics 
haunch  's  cuts  when  the  countdown  reaches  zero. 

IN  FLIGHT  CONTROLS 

1  The  In-Flight  Display 

After  the  missile  is  launched,  the  display  changes  to  the  in-flight  display 
own  m  Figure  9.5.  The  left  Bide  of  the  display  contains: 

-  A  three-dimensional  view  of  the  terrain  as  seen  from  the  missile’s  camera. 

A  slider  bar  scale  along  the  bottom  edge  indicating  the  camera  pan  angle. 
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-  A  slider  bar  scale  along  the  left  hand  edge  indicating  the  camera  tilt  angle. 

-  A  box  in  the  lower  left  corner  containing  either  the  word  DESIGNATE  or 
REJECT.  The  word  DESIGNATE  in  this  box  indicates  that  the  missile  is 
not  locked  on  to  a  target  and  is  waiting  for  a  command  to  designate  one. 
The  word  REJECT  indicates  that  the  missile  is  locked  on  to  a  target  and  is 
waiting  for  a  command  to  reject  that  target. 

-  CrosB  hairs  used  to  sight  the  camera  onto  a  target. 

The  upper  right  corner  of  the  display  contains  a  scaled  copy  of  the  contour  map 
seen  in  the  prelaunch  phase.  The  red  arrow  superimposed  on  the  contour  map 
shows  the  missile’s  current  position  (the  tail  of  the  arrow)  and  its  direction  of 
flight.  The  red  rectangle  on  the  map  indicates  that  area  of  the  terrain  that  is 
currently  being  shown  in  the  three-dimensional  display. 

The  middle  right  section  of  the  display  contains  four  indicators  which 
show  the  following: 

-  The  speed  of  the  missile  in  knots. 

-  The  direction  the  missile  is  traveling  in  degrees. 

-  The  height  of  the  missile  above  ground  level  (AGL)  in  feet. 

-  The  height  of  the  missile  above  mean  sea  level  (MSL)  in  feet. 

-  A  slider  bar  indicating  the  zoom  setting  of  the  camera  in  degrees. 

The  lower  right  section  of  the  display  contains  a  summary  of  the  functions 
performed  by  the  mouse  and  dials.  These  are  explained  further  below.  The  in¬ 
flight  phase  continues  until  the  missile  impacts  a  designated  target  or  all  three 
mouse  buttons  are  pressed  simultaneously  (to  stop  the  execution  of  the 
simulation). 
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2.  Controlling  the  Camera 


The  ranges  and  initial  values  of  the  camera’s  functions  are  shown  in 
Table  0.1.  All  6f  the  camera's  functions  are  controlled  with  the  mouse. 

-  To  pan  the  camera,  move  the  mouse  left  or  right  as  needed. 

-  To  tilt  the  camera,  move  the  mouse  up  or  down  as  needed. 

-  To  zoom  in  to  a  tighter  field  of  view,  press  the  left  mouse  button. 

-  To  zoom  out  to  a  wider  field  of  view,  press  the  right  mouse  button. 

3.  Controlling  the  Missile  Flight 

The  missile  can  be  controlled  by  changing  its  direction,  speed,  and 
altitude.  The  ranges  and  initial  values  of  each  of  the  flight  parameters  is  shown 
in  Table  9.2.  The  missile  flight  parameters  are  controlled  by  using  the  dials  on 
the  IRIS’s  button/dial  box  (see  Figure  9.6).  Dial  zero  (lower  left)  controls  the 
missile’s  direction,  dial  one  (lower  right)  controls  the  missile’s  altitude,  and  dial 
two  (above  dial  zero)  controls  the  missile’s  speed.  Refer  to  the  display’s  control 


TABLE  9.1  CAMERA  CONTROL  RANGES  AND  INITIAL  VALUES 


Control 

Ran, 

ge 

Initial  Value 

Maximum 

Minimum 

Pan 

Tilt 

Zoom 

25  degrees  right 

25  degrees  down 
55  degrees 

25  degrees  left 
15  degrees  up 

8  degrees 

0  degrees 

15  degrees  down 
55  degrees 

TABLE  9.2  MISSILE  CONTROL  RANGES  AND  INITIAL  VALUES 


Control 

Rang 

rp 

r 

Initial  Value 

Maximum 

Minimum 

Altitude 

Speed 

Direction 

1  . 

’ 

200  AGL 

200  kts 

From  prelaunch 

100 


summary  box  for  a  reminder  of  each  dial's  purpose  and  location  during  flight. 
The  controls  are  used  as  follows: 

-  Direction  of  flight  -  Turning  dial  zero  clockwise  turns  the  missile  to  the 
right.  Turning  it  counterclockwise  turns  it  to  the  left.  The  missile  will  move 
freely  through  the  360  degree  mark  so  that,  for  example,  turning  the  missile 
right  two  degrees  from  a  heading  of  359  degrees  will  produce  a  heading  of 
001. 

-  Altitude  -  Turning  dial  one  clockwise  increases  the  missile’s  altitude  up  to 
the  maximum  of  10,000  feet  MSL.  Turning  the  dial  counterclockwise 
decreases  the  missile's  altitude.  The  simulator  will  not  allow  an  altitude  to 
be  selected  that  is  less  than  200  feet  above  ground  level. 

-  Speed  -  Turning  dial  two  clockwise  increases  the  missile’s  speed,  while 
counterclockwise  decreases  the  speed. 

4.  Designating  and  Rejecting  Targets 

The  middle  mouse  button  is  used  to  designate  (lock  on  to)  and  reject 

(release  the  lock  on)  targets.  When  the  missile  is  not  locked  on  to  a  target  the 

word  DESIGNATE  will  appear  in  the  lower  left  corner  of  the  display.  To 

designate  a  target,  center  the  target  within  the  cross  hairs  and  press  the  middle 

mouse  button.  In  order  for  the  missile  to  lock  on,  some  portion  of  the  target 

must  be  in  the  center  of  the  cross  hairs.  If  the  designation  is  successful,  the 

workstation  will  “beep”  and  word  REJECT  will  appear  in  place  of  the  word 

DESIGNATE  on  the  display.  Once  a  target  is  designated  the  missile  will 

automatically  adjust  its  heading  and  altitude  to  home  in  on  the  selected  target. 

An  explosion  is  displayed  after  impact  with  the  target  occurs.  The  user  is  then 

returned  to  the  prelaunch  phase  of  the  simulation  to  begin  another  launch. 
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A  locked  on  target  can  be  rejected  and  missile  flight  control  returned  to 
the  user  by  pressing  the  middle  mouse  button  any  time  before  impact  with  the 
target  occurs.  The  workstation  will  respond  with  a  “beep”  and  the 
reject /designate  box  will  again  show  the  word  DESIGNATE.  The  missile  is  now 
ready  to  accept  the  designation  of  a  new  target. 
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X.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  LIMITATIONS 

There  are  several  limitations  to  the  flight  simulator  presented  in  this  study. 
First,  a  trade-off  had  to  be  made  between  resolution  and  frame  update  (display) 
speed.  Even  though  data  was  available  at  a  resolution  of  twelve  and  one-half 
meters,  the  simulator  uses  one  hundred  meter  resolution  in  order  to  achieve  an 
acceptable  frame  update  rate. 

Second,  the  simulator’s  flight  is  confined  to  a  ten  kilometer  square  area.  Any 
ten  kilometer  square  area  of  the  DTED  file  can  be  used  during  a  run  of  the 
simulation,  but  the  simulator  must  be  exited  before  switching  to  a  new  area.  This 
limitation  is  not  too  restrictive  for  the  current  range  of  the  FOG-M,  but  may  be 
inadequate  if  the  range  of  the  missile  is  increased  as  planned. 

Third,  road  data  is  available  in  a  format  usable  by  the  simulator  for  only  one 
10  kilometer  square  area.  Since  access  routines  were  not  developed  for  the  DFAD 
data  file,  roads  must  be  digitised  by  hand. 

Fourth,  the  simulator  does  not  model  any  of  the  missile’s  flight  dynamics.  As 
stated  earlier,  this  limitation  was  imposed  only  because  of  development  time 
constraints.  It  is  felt  that  the  dynamics  can  be  acceptably  modeled  without 
adversely  affecting  the  performance. 


B.  FUTURE  RESEARCH  AREAS 


A  follow-on  to  this  project,  which  will  provide  more  realistic  targets  and 
allow  viewing  of  the  scene  as  seen  from  inside  any  of  them,  is  currently  underway 
at  the  Naval  Postgraduate  School.  The  project's  plans  are  to  use  the  Ethernet  to 
allow  several  workstations  to  take  part  in  the  simulation  simultaneously.  Each 
workstation  will  control  one  weapon  (a  target  or  the  missile)  and  its  monitor  will 
display  the  scene  as  viewed  from  that  weapon. 

Work  is  also  underway  at  the  Naval  Postgraduate  School  in  the  use  of 
digitised  photographic  images  on  the  IRIS.  This  work  could  possibly  be 
incorporated  into  the  FOG-M  project  through  the  use  of  digitized  target  images, 
digitised  cultural  features,  or  digitised  textures  for  the  terrains. 

Another  possible  research  area  is  the  addition  of  various  environmental  effects 
into  the  simulation.  These  include  clouds,  smoke,  and  rain,  which  affect  the 
camera’s  view  by  reducing  visibility,  and  also  dust,  which  aids  the  missile 
operator  in  acquiring  moving  targets. 

Much  work  could  be  done  in  the  area  of  the  missile’s  flight  dynamics.  The 
goal  would  be  to  provide  an  acceptably  accurate  model  without  too  much  of  a 
sacrifice  in  speed. 

C.  SUMMARY  AND  CONCLUSIONS 

The  project  has  proven  the  practicality  and  feasibility  of  building  a  low-coat 
flight  simulator  with  commercial,  off-the-shelf  hardware.  With  a  relatively  small 
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investment  of  time  and  funds,  a  simulator  with  significant  capabilities  was 
developed.  As  the  speed  and  power  of  graphics  hardware  increases,  even  more 
realistic  displays  at  faster  update  rates  will  be  possible. 


APPENDIX  A  -  MODULE  DESCRIPTIONS 


BUILD  ROAD.C 

Input:  None. 

Output:  None. 

Side  Effects:  Modifies  the  global  array  road ,  an  array  of  graphical  objects,  where 
each  object  contains  the  polygons  representing  the  road  in  a 
particular  gridsquare. 

Description:  Build_road  reads  the  file  road  width  and  centerline  information 
from  the  file  Road.data  and  constructs  polygons  which  represent 
the  road.  The  polygons  are  stored  in  the  array  of  graphical  objects 
road.  A  more  detailed  discussion  of  building  the  roads  is  contained 
in  Chapter  VIII. 

BUILDTERRAIN.C 

Input:  None. 

Output:  None. 

Side  Effects:  Buildterrain  modifies  the  global  arrays  savetriangle  and  grideolor. 

Description:  Buildterrain  reads  terrain  height  information  from  the  global  array 

gridpixel  and  constructs  the  terrain  as  a  set  of  planar  triangles. 
The  details  of  constructing  the  triangles  and  the  format  of  the 
aavetriangle  and  grideolor  arrays  can  be  found  in  Chapter  VI. 

COLORRAMP.C 

Input:  The  inputs  to  eolorramp  are  two  booleans,  greyscale  and  init.  If 

greyscale  is  TRUE,  the  terrain,  sky,  and  target  colortable  entries 
are  defined  in  shades  of  grey  to  produce  a  black-and-white  image. 
If  greyscale  is  F ALSE,  the  terrain  colors  are  green,  the  sky  is  blue, 
and  targets  are  brown.  Init  is  set  to  TRUE  when  this  routine  is 
initially  called,  so  that  every  entry  in  the  colortable  is  defined, 
including  those  for  terrain,  sky,  targets,  and  writemasked  lines  on 
top  of  the  contour  maps.  Should  the  display  be  switched  between 
color  and  black-and-white,  only  the  terrain,  sky,  and  target  entries 
need  to  be  redefined,  which  is  what  happens  when  init  is  FALSE. 

Output:  None. 

Side  Effects:  Colorramp  changes  the  system's  colortable,  and  thus  determines 
the  colors  that  appear  on  the  display  for  the  images  drawn  by 
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other  routines. 

Description:  Colorramp  is  called  by  the  mc'n  program  fogzn  as  part  of  the 
initialization  that  takes  place  before  the  flying  loop  is  entered.  At 
that  point,  greyscale  is  set  to  its  default  value  (usually  FALSE, 
indicating  color  images)  and  init  is  TRUE.  The  readeontrols 
routine  also  calls  colorramp  to  toggle  the  display  image  between 
color  and  black-and-white,  based  on  the  position  of  one  of  the 
dials.  This  call  is  made  with  the  desired  value  for  greyscale  and 
with  init  FALSE.  Colorramp  uses  the  IRIS  routine  mapeolor  to 
directly  update  the  colortable  for  the  contour  map  colors,  and  calls 
the  user  written  routine  gammaramp  to  define  appropriately 
shaded  ranges  of  the  greens  and  browns  (or  greys)  used  for  the 
terrain  and  targets. 

COMPASS.C 

Input:  Compass  takes  as  input  a  float,  direction ,  which  is  an  angle  in 

radians. 

Output:  Compass  returns  a  float  which  is  the  compass  direction  in  degrees 

corresponding  to  the  input  direction. 

Side  Effects:  None. 

Description:  The  function  Compass  converts  an  radian  angle  measured  using 
the  standard  mathematical  convention,  and  converts  it  to  a  degree 
angle  measured  using  the  standard  navigational  convention. 

DISP  TER.RAIN.C 

Input:  Display  terrain  takes  eleven  inputs:  the  X,  Y ,  and  Z,  coordinates 

of  the  missile  position  VX,  VY,  and  VZ\  the  X ,  Y,  and  Z 
coordinates  of  the  camera’s  look-at  position  PX ,  PY,  PZ\  the  field 
of  view  angle  (camera  zoom  value),  FOVY ;  and  the  X  and  Z 
ranges  of  gridsquares  to  be  displayed,  FIRST  X,  FIRSTZ, 
LAST  X  and  LAST  Z. 

Output:  None. 

Side  Effects:  None. 

Description:  Disp  terrain  outputs  a  frame  of  the  terrain  scene  to  the  monitor 
using  a  hidden  surface  algorithm.  The  scene  contains  terrain, 
roads,  and  targets.  Details  of  the  hidden  surface  algorithm  can  be 
found  in  Chapter  VI. 
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DIST  TO  LOS.C 

Input:  Diet  Jo  Jos  takes  seven  inputs:  the  X,  Y,  and  Z  coordinates  of  the 

start  of  a  line  segment;  the  X,  Y,  and  Z  coordinates  of  the  end 
point  of  a  line  segment;  and  three  dimensional  array,  pt,  which 
contains  the  coordinates  of  a  point. 

Output:  Diet  Jo  Jos  returns  a  float  which  is  the  perpendicular  distance 

from  the  input  point,  pt,  to  the  input  line. 


Side  Effects:  None. 


Description:  Function  which  computes  the  perpendicular  distance  from  a  point 
to  a  line  in  three-space. 


DO  BOUND ARY.C 

Input:  Dojoxindary  takes  the  following  inputs: 

-  An  integer  Bound Jype  which  is  interpreted  as: 

0  -  a  diagonal  boundary 

1  -  a  horizontal  boundary 

2  -  a  vertical  boundary 

-  An  integer  which  triangle  that  is  interpreted  as: 

0  -  the  lower  triangle  of  the  gridsquare. 

1  -  the  upper  triangle  of  the  gridsquare. 

-  The  indices,  xgrid  and  zgrid,  of  the  gridsquare  for  which  the  road 
is  being  constructed. 

-  The  coordinates  of  the  start  point  of  the  boundary  stored  in  a 
three  dimensional  array,  bound  start. 

-  The  coordinates  of  the  end  point  of  the  boundary  stored  in  a 
three  dimensional  array,  bound  end. 

-  The  coordinates  of  the  start  point  of  the  left  side  of  the  road 
stored  in  a  three  dimensional  array,  left  start. 

-  The  coordinates  of  the  end  point  of  left  side  of  the  road  stored  in 
a  three  dimensional  array,  left  end. 

-  The  coordinates  of  the  start  point  of  the  right  side  of  the  road 
stored  in  a  three  dimensional  array,  right  start. 

-  The  coordinates  of  the  end  point  of  right  side  of  the  road  stored 
in  a  three  dimensional  array,  right  end. 

-  A  boolean,  start  corner  flag ,  which  is  TRUE  if  the  gridsquare 
corner  at  the  boundary’s  start  is  ALREADY  in  the  road  polygon 
array,  FALSE  otherwise. 

-  A  boolean,  end  corner  flag,  which  is  TRUE  if  the  gridsquare 
corner  at  the  boundary’s  end  is  ALREADY  in  the  road  polygon 
array,  FALSE  otherwise. 

-  The  partially  complete  road  polygon  array,  road  poly. 


-  An  integer,  vcrtcxcnt,  that  is  the  number  of  vertices  currently  in 
the  roadjpoly  array. 

Output:  Do  Jioundary  outputs  the  following: 

-  start _corner  flag  (see  Inputs  for  a  description) 

-  end jcorner _flag  (see  Inputs  for  a  description) 

-  road_poly ,  the  road  polygon  array  with  the  vertices  along  this 
boundary  added. 

-  vcrtex_cnt  (see  Inputs  for  a  description) 

Side  Effects:  None. 

Description:  Do -boundary's  purpose  is  to  find  all  the  intersections  of  the  road’s 

left  and  right  sides  with  the  input  boundary  of  a  grid  triangle.  As 
an  intersection  is  found  the  point  is  put  into  a  temporary  array. 
After  all  the  intersections  are  found  for  the  boundary  the  points  in 
the  temporary  array  are  sorted  then  added  to  the  existing 
road_poly  array.  The  order  of  the  sorting  is  such  that  the  resulting 
road  poly  array  will  be  ordered  counterclockwise.  See  Chapter 
VIII  for  a  detailed  description  of  building  the  roads. 

EDIT  INDBOX.C 

Input:  The  inputs  to  editjndbox  are  the  name  of  the  indicator  object,  the 

tags  within  that  object  for  each  of  the  indicators,  and  current 
values  for  the  following  missile  parameters:  X,  T,  and  Z  position 
coordinates,  pan,  tilt,  and  zoom  angles,  and  designate/reject 
status. 

Output:  None. 

Side  Effects:  Since  edit_indbox  changes  the  indicator  object,  it  has  the  side 
effect  of  changing  the  display  when  the  indicator  object  is  next 
called  and  displayed. 

Description:  The  indicator  object  is  edited  between  each  display  frame  so  that 
the  heads-up  display  and  the  indicator  box  indicators  show  the 
current  values  for  the  missile’s  speed,  heading,  altitude,  camera 
pan  angle,  camera  tilt  angle,  camera  field  of  view  (zoom),  and 
designate/reject  status.  The  input  speed,  heading,  and  MSL 
altitude  ( Y  position  coordinate)  are  converted  to  strings  for 
display.  AGL  altitude  is  calculated  as  the  difference  between  MSL 
altitude  and  the  elevation  of  the  ground  directly  below  the  missile 
as  obtained  from  gndjevcl  with  the  X  and  Z  position  coordinates 
as  input.  The  boolean  designate  determines  whether 
“DESIGNATE”  or  “REJECT”  is  printed  in  the  lower  left  corner 
of  the  terrain  display.  Finally,  the  positions  of  the  tilt,  pan,  and 


zoom  indicators  are  calculated  from  the  missile  parameters.  The 
equations  in  the  code  have  been  simplified  to  avoid  excess 
computation;  the  derivations  are  given  below. 

The  x  screen  coordinate  of  the  zoom  (field  of  view,  or  fov)  indicator 
is  fixed.  The  y  screen  coordinate  varies  from  200  (at  8°  fov)  to  70 
(at  55°  fov).  The  input  missile  parameter  zoom  is  in  tenths  of 
degrees,  and  thus  ranges  from  80  to  550.  The  y  coordinate  is 
determined  from  Equation  A.l. 


|  zoom 

-  8 

200  - 

* 

70 

10 

55  - 

8 

(A.l) 

=  zoom  *  -0.2766  +  222.128 


Likewise,  the  screen  x  coordinate  of  the  tilt  indicator  is  fixed,  while 
the  y  coordinate  varies  from  680  (at  +25°  tilt)  to  50  (at  -25°  tilt). 
The  input  missile  parameter  tilt  is  in  radians,  and  is  converted  to 
degrees  by  multiplying  it  with  the  RTOD  (Radians  TO  Degrees) 
constant  from  the  header  file  fogm.h.  The  y  coordinate  of  the  tilt 
indicator  is  calculated  as  shown  in  Equation  A.2. 
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50  + 


|  [  (tilt  *DTOR)  +  25] 


680  -  50 
*  _____ 

25  -  -25 


(A.2) 


=  tilt  *  721.92682  +  365 


The  pan  slider  bar  is  horizontal,  so  the  y  coordinate  is  fixed,  and 
the  x  coordinate  ranges  from  120  (at  -25°  pan)  to  750  (at  +25° 
pan).  Like  tilt,  the  pan  value  is  in  radians  and  must  be  converted 
to  degrees.  The  pan  indicator  x  coordinate  is  given  by  Equation 
A.3. 


x  =  750  -|  [  {pan  *  DTOR)  4  25]  * 


750  -  120 
25  -  -25 


(A.3) 


=  pan  *  -721.92682  +  435 


EXPLOSION.C 

Input:  None. 

Output:  None. 

Side  Effects:  None. 

Description:  The  explosion  routine  simulates  the  effect  of  a  missile  destroying  a 
target  by  rapidly  flashing  a  succession  of  red,  black,  and  yellow 
screens.  One  buffer  is  kept  black  to  pronounce  the  flash  effect,  and 
the  other  buffer  is  alternately  cleared  to  red,  yellow,  red,  yellow, 
and  red.  A  short  pause  with  a  cleared,  black  screen  is  provided 
before  the  routine  exits. 

FOGM.C 

Input:  Fogm  is  the  name  given  to  the  main  program  in  the  simulator.  It 

has  no  parameters,  but  gets  data  from  its  header  files  and  through 
the  readdata  routine.  Interactive  input  is  also  received  vial  the 
readeontrola  routine. 

Output:  None. 

Side  Effects:  None. 

Description:  The  fogm  program  consists  of  global  variable  declarations,  local 
variable  declarations,  system  initializations,  an  active  loop,  and 
some  exit  housekeeping.  The  initialization  portion  includes  reading 
in  the  DMA  elevation  data,  making  network  connection  (if  in  use), 
setting  the  IRIS  display  configuration,  defining  the  color  table 
entries,  building  all  of  the  graphical  objects  used  in  the  displays, 
and  computing  the  lighting  and  position  of  the  polygons  used  to 
produce  the  terrain  image.  Within  the  active  loop  is  some 
additional  initializations  and  the  flying  loop.  In  the  active  loop 
initializations,  the  dial  and  mouse  controls  are  reset  to  their  initial 
defaults,  and  the  display  buffers  are  loaded  with  the  images  that 
remain  unchanged  during  flight  simulation  (the  contour  map  and 
the  legend/instruction  box).  Control  is  then  passed  to  the  flying 
loop,  which  produces  the  flight  simulation  images  until  either  a 
target  is  hit  or  the  simulation  exit  command  is  received.  If  a  target 
was  hit,  an  explosion  is  displayed  and  the  pre-launch  phase  of 
designating  launch  and  target  positions  is  re-entered.  If  all  three 
mouse  buttons  have  been  pressed,  the  display  is  cleared  and 
various  system  parameters  are  reset  to  provide  a  graceful  exit  from 
the  simulator. 


The  flying  loop  contains  the  subroutine  calls  that  produce  the 
simulation  of  flight.  First,  the  mouse  and  dials  are  checked  for 
control  input.  Then  the  targets',  missile's,  and  lookat  reference 
point’s  positions  are  all  updated  based  on  the  elapsed  time  since 
the  previous  frame  and  the  appropriate  speeds.  View  bound*  is 
called  to  determine  which  one  kilometer  grid  squares  are  in  view, 
and  then  the  indicators  are  all  updated  to  show  the  new  control 
values,  missile  statistics,  and  view  area.  The  main  display  routine 
then  draws  the  appropriate  sections  of  the  terrain,  plus  cultural 
features  and  targets  where  appropriate.  Finally,  the  updated 
indicator  objects  are  drawn,  and  the  display  buffers  are  swapped  to 
display  the  newly  created  image. 


GAMMARAMP.C 


Input:  The  inputs  to  gammaramp  are  a  correction  factor,  a  color  table 

starting  index,  the  number  of  color  table  entries  (shades)  to  be 
defined,  red,  green,  and  blue  intensities  for  the  brightest  color  to  be 
defined,  and  finally,  red,  green,  and  blue  intensities  for  the  darkest 
color  to  be  defined. 


Output:  None. 

Side  Effects:  Gammaramp  has  the  side  effect  of  defining  entries  in  the  system 
color  table. 

Description:  Displayed  colors  do  not  correspond  linearly  to  the  numeric  red, 
green,  and  blue  intensity  values  that  are  used  to  produce  them.  If  a 
range  of  colors  (0  ..  #colors-l)  is  defined  in  the  straightforward  way 
with  a  uniform  increment,  the  intensity  of  the  n  color  (7J  is 
given  by  Equation  A. 4,  and  the  bright  colors  will  appear  more 
widely  spaced  than  the  dark  colors. 

Maxi  -  Mini 

In  =  n  * - +  Mini  (A.4) 

4  color* 


Gammaramp  avoids  this  by  using  a  power  function  to  increase 

spacing  between  the  dark  colors’  intensity  values  and  to  decrease 

the  intensity  increment  as  the  colors  get  brighter.  The  strength  of 

the  correction  is  determined  by  a  value  7,  which  is  constant  for  a 

given  range,  but  must  be  experimentally  determined  for  each  range 

that  differs  in  color  or  number  of  colors.  FOG-M  uses  a  7  value  of 

(A 

1.5.  The  intensity  of  the  n  color  in  a  gammaramp  created  table  is 
given  by  Equation  A. 5. 
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(A.5) 


GET  TGT 
Input: 

Output: 

Side  Effects: 

Description: 


I - |  *  (Maxi  -  Mini)  +  Mini 

\  ^colors- 1  ) 


POS.C 

The  input  to  gct_tgtjpoa  is  &  socket  number  for  Ethernet 
communication  (if  in  use),  a  boolean  indicating  designate/reject 
status,  the  index  of  the  currently  designated  target,  and  the 
“name”  of  the  tank  object. 

Output  is  the  new  X,YtZ  position  coordinates  of  the  currently 
designated  target. 

Get  tgt  pos  updates  several  global  data  structures.  It  sets  the 
number  of  target  images,  updates  the  target  position  arrays,  and 
updates  the  array  of  target  object  names. 

The  primary  purpose  of  get_tgt_poa  is  to  move  the  targets  in  the 
simulation.  If  the  networking  capability  is  in  use,  the  target 
positions  for  the  next  frame  are  received  over  the  network.  When 
networking  is  not  in  use,  targets  are  moved  at  a  set  speed  of  fifteen 
knots,  and  reverse  course  when  they  reach  the  boundaries  of  the 
ten  kilometer  square  terrain  area.  As  explained  in  Chapter  VII,  an 
array  of  graphical  objects  is  defined  to  match  one  object  per  one 
hundred  meter  square  of  terrain,  and  this  array  is  also  used  as 
booleans  to  indicate  the  presence  or  absence  of  targets  in  the  one 
hundred  meter  grid  square.  Gcttgtpoa  begins  by  removing  each 
target  from  this  array.  New  target  positions  are  calculated  or 
received  over  the  network.  If  one  of  the  targets  has  been  “locked- 
onto,”  its  new  position  is  returned  to  be  used  as  the  current  aim 
point  for  the  missile.  This  is  easily  determined  if  networking  is  off 
because  the  designated  target's  index  remains  the  same  and  the 
new  position  can  be  directly  accessed.  The  index  correspondence  is 
not  guaranteed  when  networking,  so  the  index  of  the  new  target 
whose  coordinates  are  closest  to  the  old  targeted  point  is  used. 

Targets  that  straddle  a  one  hundred  meter  grid  square  boundary 
must  be  drawn  on  top  of  both  (or  possibly  all  four)  grid  squares  in 
order  to  avoid  being  partially  obscured  by  whichever  square  is 
drawn  last.  (The  target  must  be  drawn  immediately  after  the  grid 
square  on  which  it  rests  to  ensure  that  the  target  will  be  obscured 
when  it  should  be  by  terrain  drawn  in  the  foreground.)  Since  the 
calculation  of  boundary  intersection  requires  several  trigonometric 
functions  plus  an  allowance  for  the  distance  between  the  center  of 


the  tank  and  its  boundaries  (which  varies  with  the  direction  of  the 
tank),  a  simplifying  algorithm  is  used.  If  the  tank  is  close  enough 
to  a  boundary  that  the  most  distant  part  of  the  tank  might  cross 
the  boundary,  the  target  is  also  drawn  after  the  adjoining  grid 
square(s)  (see  Figure  7.3).  This  is  done  by  adding  a  “new”  target 
to  the  array  of  target  objects.  The  “new”  target  object  is  drawn  at 
the  exact  same  location  in  the  three-dimensional  terrain,  but  it  is 
drawn  after  a  different  one  hundred  meter  grid  square,  so  it  will 
have  different  target  object  array  indices,  and  be  in  a  separate 
target  object. 

After  all  of  the  targets  (originals  and  boundary  copies)  have 
updated  positions  and  target  object  army  indices,  objects  are 
added  to  the  target  object  army  as  described  in  Chapter  VII.  This 
army  is  then  used  by  the  terrain  display  routine  to  actually  draw 
the  targets. 

GND  LEVEL.C 

Input:  Gndlcwl  takes  as  inputs  the  X  and  1  coordinates  of  the  point  for 

which  the  elevation  is  desired. 

Output:  Gndjtvtl  returns  a  float  which  is  the  elevation  at  point  X  and  Z. 

Side  Effects:  None. 

Description:  Gnd_level  computes,  through  interpolation,  the  scaled  elevation  of 

any  point  within  the  terrain  boundaries.  A  calculation  is  done  to 
determine  which  gridtriangle  contains  the  point.  Then,  using  the 
known  elevations  at  the  vertices  of  the  triangle,  the  elevation  of  the 
point  is  found. 

IN  THIS  POLY.C 

Input:  InJhi$_poly  takes  the  following  inputs: 

-  An  army  of  points,  polygon ,  which  define  a  polygon.  (Note:  only 
the  X  and  Z  coordinates  of  the  points  are  used,  the  Y  value  is 
ignored). 

-  An  integer,  numvertcz,  that  is  the  number  of  vertices  in 
polygon. 

-  A  point,  pnt ,  that  is  to  be  tested.  (Note:  only  the  X  and  Z 
coordinates  of  the  point  is  used,  the  Y  value  is  ignored). 

Output:  In  this  poly  returns  a  boolean  which  is  TRUE  if  pnt  is  inside  the 

polygon  defined  by  polygon ,  FALSE  otherwise. 


Side  Effects:  None. 

Description:  In_this_poly  is  s  function  which  tests  whether  a  point  is  inside  a 
given  polygon,  where  both  the  point  and  the  polygon  are  in  the  XZ 
plane.  The  algorithm  used  constructs  a  bounding  box  around  the 
polygon.  If  the  point  lies  outside  the  bounding  it  obviously  can 
not  be  inside  the  polygon.  If  the  point  lies  inside  the  bounding  box 
a  further  test  is  made.  A  line  is  constructed  from  a  point  outside 
the  bounding  box  to  the  point  to  be  tested.  Each  of  the  edges  of 
the  polygons  are  then  tested  to  see  if  they  intersect  the  constructed 
line  and  a  count  is  kept  of  the  number  that  do  intersect.  The 
point  lies  inside  the  polygon  if  and  only  if  the  constructed  line 
intersects  an  odd  number  of  the  polygon’s  edges. 

INITCTRLS.C 

Input:  Iniijctrls  takes  as  inputs  the  initial  altitude  of  the  missile,  in  feet; 

the  initial  heading  of  the  missile  in  degrees;  and  a  boolean, 
greyscale ,  which  is  TRUE  if  greyscaled  terrain  is  to  be  displayed 
and  FALSE  if  color  terrain  is  to  be  displayed. 

Output:  Initctrls  has  as  outputs  the  initial  pan  angle  of  the  camera  in 

radians;  the  initial  tilt  angle  of  the  camera  in  radians,  and  the 
initial  zoom  setting  of  the  camera  in  tenths  of  a  degree. 

Side  Effects:  The  MOUSEX,  MOUSEY ,  DIALO,  DIALl ,  DIAL2,  and  DIALZ 
valuators  are  set  as  a  result  of  calling  this  routine. 

Description:  Init  ctrls's  purpose  is  to  initialize  the  mouse  and  dial  valuators 
used  for  the  operator  controls.  The  initial  altitude,  heading,  and 
greyscale  valuator  settings  are  passed  in  as  inputs.  The  pan,  tilt, 
and  field  of  view  settings  are  read  from  an  "include''  file  and  their 
values  passed  back  as  outputs. 

INIT  IRIS.C 

Input:  None. 

Output:  None. 

Side  Effects:  Calling  this  routine  sets  the  Iris  attributes  and  configures  the  Iris. 

Description:  Initjiris  accomplishes  the  following:  it  puts  the  Iris  into 
doublebuffer  mode,  sets  the  chunksize  (the  minimum  memory 
increment  used  in  objects),  sets  the  monitor  type  to  either  NTSC 
or  HZ60,  and  enables  backface  polygon  removal. 


INITTGTS.C 

Input:  None. 

Output:  None. 

Side  Effects:  Inittgts  always  initializes  the  global  target  object  array  to  all 
zeros.  If  target  data  is  not  being  received  over  the  network, 
inittgts  also  defines  ten  targets  by  setting  initial  values  in  the 
global  target  counter,  target  position  array,  and  target  direction 
array.  An  auxiliary  function  mittpt  is  used  to  perform  the  actual 
update  of  the  global  arrays. 

INTERP  ELEV.C 

Input:  Interp_elev  takes  three  inputs,  each  an  array  of  X ,  Y,  and  Z 

coordinates,  representing  a  point.  One  array  is  the  start  point  of  a 
line,  the  second  array  is  the  end  point  of  a  line,  and  the  third  array 
is  a  point  along  the  line. 

Output:  Interpjelev  returns  a  float  that  is  the  elevation  value  of  the  point 

along  the  line. 

Side  Effects:  None. 

Description:  Interpclcv  returns  a  float  which  is  the  linear  interpolation  of  the 
Y  (elevation)  coordinate  of  the  point  along  the  line,  based  on  the 
elevations  at  the  start  and  end  points  of  the  line. 

LIGHT  ORIENT.C 

Input:  Light  orient  takes  as  inputs  the  following: 

-  An  array  of  coordinates  for  the  polygon. 

-  An  integer,  numjcoordt,  the  number  of  coordinates  in  the 
polygon. 

-  The  X ,  Y,  and  Z  coordinates  of  a  point  that  is  "behind"  the 
polygon  (an  interior  point). 

-  The  X,  Y,  and  Z  coordinates  of  a  light  source. 

•  The  minimum  and  maximum  color  map  indices  to  be  used  for 
this  polygon. 

Output:  Light  jorient  returns  the  color  map  index  of  the  color  to  use  in 

lighting  this  polygon.  It  also  reorders  the  polygon  array  (if 
necessary)  so  that  the  points  are  ordered  counterclockwise. 

Side  Effects:  None. 

Description:  Light_orient  computes  a  lighting  for  a  polygon  based  on  Lambert's 
cosine  law,  which  states  that  the  intensity  of  the  light  reflected 
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from  an  object  is  proportional  to  the  cos(ff),  where  #  is  the  angle 
of  incidence  of  the  light  ray.  (see  Figure  5.2).  Lifkt_orient  also 
orders  the  vertices  of  the  polygon  in  a  counterclockwise  fashion  so 
that  backface  polygon  removal  can  take  place  (see  the  module 
description  for  npoly  oricni). 


LINE  INTER2.C 

Input:  Line_inter2  takes  the  following  inputs: 

-  An  array  containing  the  X  and  1  coordinates  of  the  start  point  of 
lineone  is  ignored.) 

-  An  array  containing  the  X  and  Z  coordinates  of  the  end  of 
line  one.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

-  An  array  containing  the  X ,  Y ,  and  Z  coordinates  of  the  start  of 
line  two.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

-  An  array  containing  the  X,  Y,  and  Z  coordinates  of  the  end  of 
line  two.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

Output:  Line _inter2  returns  as  outputs: 

-  An  array  containing  the  X  and  Z  coordinates  of  the  intersection 
of  line  one  and  line  two.  If  the  lines  do  not  intersect  these  values 
are  undefined  not  considered  in  the  calculation). 

-  An  integer  which  can  be  interpreted  as  follows: 

0  •  the  lines  do  not  intersect. 

1  -  the  lines  intersect,  but  the  intersection  uses  an 
extension  of  at  least  one  of  the  lines  past  its  start  or 
end  points. 

2  -  the  lines  intersect,  and  the  intersection  occurs 
between  the  input  start  and  end  points  of  both  lines. 

Side  Effects:  None. 

Description:  Line  inter2  computes  the  point  of  intersection  between  two  lines 
in  the  XZ  plane.  The  type  of  intersection,  as  explained  above  in 
"Output"  is  also  determined.  Throughout  the  routine,  three 
element  arrays  are  used  for  compatibility  with  other  routines.  The 
second,  K,  coordinate  is  not  considered  in  any  of  the  calculations. 


MAKEINDBOX.C 

Input:  None. 
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Output:  Mokeindbox  return*  a  graphical  object  “name,”  tags  for  editing  the 

•peed,  direction,  altitude,  and  designate /reject  readouts,  and  tags 
for  editing  the  zoom,  pan,  and  tilt  indicators. 

Side  Effects:  None. 

Description:  Mokeindbox  generates  a  graphical  object  that  contains  both  the 

indicator  box  in  the  middle  of  the  displays  on  the  right  side  of  the 
screen  and  the  “heads-up”  display  that  is  superimposed  on  the 
terrain  image  (Figure  6.8).  The  object  consists  almost  entirely  of 
straightforward  line  and  character  string  drawing  commands,  but 
there  are  two  interesting  points.  First,  within  a  single  object,  there 
are  two  different  coordinate  systems:  one  for  the  indicators 
superimposed  on  the  terrain,  and  smother  for  the  separate  indicator 
box.  This  is  accomplished  with  an  ortho 2  call  for  each  coordinate 
system,  and  by  bracketing  each  ortho 2  with  pushmatriz  and 
popmatrix  commands.  Note  that  the  heads-up  display  is  truly 
superimposed;  it  is  specified  in  two-dimensional  screen  coordinates 
as  opposed  to  the  three-dimensional  terrain  coordinates. 

The  second  interesting  aspect  is  the  movement  of  the  slider  bar 
indicators.  Drawing  the  indicators  as  polygons  would  require  a 
sequence  of  puthmatriz,  translate ,  and  popmatrix  calls  for  each 
indicator,  with  movement  achieved  by  editing  the  translate  call.  To 
avoid  all  of  this  matrix  movement  and  multiplication,  the 
“triangle”  of  the  indicator  is  actually  an  overlapped  line  that 
“fills”  the  triangle  by  spiraling  inwards.  The  line  is  drawn  relative 
to  the  indicated  point,  with  each  segment  of  the  line  specified  as 
offsets  from  that  initial  point,  rather  than  as  absolute  coordinates 
(Figure  A.l).  Movement  of  an  indicator  triangle  defined  in  this 
way  is  achieved  by  editing  the  parameters  of  a  move 2  call  in  the 
object,  which  sets  the  current  graphics  drawing  position  to  the 
indicated  point  on  the  slider  bar  scale  Mokeindbox  is  called  once 
by  fogm  before  the  flying  loop  is  entered,  and  then  the  object  is 
edited  (to  update  the  indicator  values)  and  called  (to  display  it) 
every  frame. 


MAKEINSTRBOX  C 

Input:  None. 

Output:  Makeinttrboz  returns  the  name  of  an  object  to  fogm. 

Side  Effects:  None. 


Description:  Maktinatrbox  creates  the  object  that  produces  the  display  in  the 
lower  right  of  the  screen  (Figure  6.8)  during  flight  simulation.  This 
display  contains  the  legend  for  the  FOG-M  controls  and  the  flight 
parameters  they  affect.  Maktinatrbox  is  called  once  by  fogm  to 
create  the  object,  and  then  the  object  is  called  twice  per  flight  to 
put  the  image  into  each  buffer.  Note  that  writemasks  are  not 
necessary  as  they  are  with  makemap  and  makenavbox,  because 
nothing  else  writes  to  the  instruction  box  portion  of  the  screen 
during  flight.  The  image  thus  remains  undisturbed  in  the  bitplanes 
despite  the  changes  in  other  screen  areas. 


MAKEMAP. C 


Input: 

Output: 

Side  Effects: 
Description: 


I 


The  input  to  makemap  is  the  globally  defined  array  of  elevation 
and  vegetation  values,  gridpixel. 

The  output  from  makemap  is  a  graphical  object  “name,”  which  is 
returned  to  fogm. 

None. 

Makemap  generates  the  object  containing  the  contour  map  and 
grid  that  appear  full  screen  during  the  pre-launch  phase,  and 
appear  in  the  upper  right  comer  of  the  screen  during  flight 
simulation  (Figure  4.1).  The  map  is  produced  using  the 
methodology  described  in  Chapter  IV.  Fogm  calls  the  object 
returned  by  draweontour  twice,  in  order  to  place  the  map  image  in 
both  buffers.  The  image  is  then  protected  from  overwrite  by  a 
wr  item  ask.  Fogm  also  passes  the  object  name  to  prelaunch ,  which 
uses  it  in  much  the  same  way  as  fogm. 


MAKESCREENS.C 


Input: 

Output: 


Side  Effects: 


None. 

Makescreena  returns  an  array  of  objects:  instruction  panel, 
statistics  box,  flight  path  between  launch  and  target  endpoints, 
and  the  three  welcome  screens,  plus  tags  to  update  the  statistics 
and  flight  path. 

None. 


Description:  Makeacreena  builds  all  of  the  objects  (mostly  screens  of  text)  that 

are  used  by  prelaunch. 
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MAKETANK.C 

Input:  None. 

Output:  MtJcctank  returns  the  name  of  an  object  containing  a  single  tank, 

drawn  around  the  origin. 

Side  Effects:  None. 

Description:  Maketank  builds  a  object  that  consists  solely  of  the  drawing 
commands  to  produce  a  single  tank.  The  tank  is  thirty-two  feet 
long,  ten  feet  high,  and  ten  feet  wide.  Its  center  bottom  is  at  the 
origin  (coordinates  0,0,0),  with  its  left  side  on  the  plane  Z  =  - 5,  its 
back  on  the  plane  X  =  -15,  its  bottom  on  the  plane  Y  —  0,  and  it 
faces  to  the  right  along  the  positive  x  axis.  For  each  of  the  twenty 
polygon  faces  that  make  the  tank,  the  X,  Y,  and  Z  coordinates  of 
each  polygon  vertex  are  stored  in  an  array,  passed  to  lightorient , 
and  then  drawn  with  polf ,  the  filled  polygon  drawing  command. 
Lightorient  ensures  the  vertices  are  ordered  counter-clockwise  in 
the  array  (with  respect  to  an  interior  point)  for  backface  polygon 
removal,  and  then  calculates  the  appropriate  color  for  the  polygon 
using  the  same  lighting  model  that  is  used  for  the  terrain  (see 
Chapter  V). 

NEAREST  TGT.C 

Input:  Neareet  tgt  takes  as  inputs  the  X ,  Y,  and  Z  coordinates  of  the 

missile  position,  and  the  X ,  Y,  and  Z  coordinates  of  the  camera’s 
look-at  position.  (The  end  points  of  the  line  of  sight  vector). 

Output:  Neare»t_tgt  returns  as  output  an  integer,  tgt  idx,  which  is  the 

target  index  of  the  target  that  is  closest  to  the  line  of  sight  vector. 

Side  Effects:  None. 

Description:  For  each  of  the  existing  targets,  neorett  tgt  computes  the  distance 
between  the  target  and  the  line  of  sight  vector.  It  returns  the 
index  of  the  target  that  was  found  to  be  closest.  In  the  case  of  two 
targets  which  are  the  same  distance  apart,  the  highest  index  value 
will  be  returned. 

NPOLY  ORIENT.C 

Input:  Npoiy  orient  takes  as  input: 

-  An  integer,  num_eoords,  that  is  the  number  of  vertices  in  the 
polygon. 

-  An  array  containing  tne  coordinates  of  the  polygon. 

-  The  X,  Y,  and  Z  coordinates  of  a  point  that  is  "behind"  the 


Output: 


Side  Effects: 
Description: 


polygon  (an  "interior"  point). 

Npoly_orient  returns  as  output  an  integer  which  is  interpreted  as: 

1  -  the  vertices  of  the  polygon  are  ordered  clockwise. 

2  -  the  vertices  of  the  polygon  are  ordered 
counterclockwise. 

None. 

Npoly_orient  determines  if  the  polygon  is  ordered  clockwise  or 
counterclockwise  by  computing  two  points:  one  along  the  normal 
vector  and  the  other,  the  same  distance  from  the  polygon,  but 
along  the  vector  in  the  direction  opposite  the  normal.  Next  the 
distance  between  these  points  and  the  "interior"  point  is 
computed.  If  the  "interior"  point  is  closer  to  the  point  along  the 
normal  vector,  the  polygon  is  ordered  clockwise,  otherwise  the 
polygon  is  ordered  counterclockwise. 


PRELAUNCH.C 


Input: 

Output: 


Side  Effects: 


The  input  to  prelauneh  is  two  arrays.  The  first  contains  objects, 
and  the  second  contains  tags  for  editing  those  objects. 

Prelauneh  returns  the  X,  Y,  and  Z  coordinates  of  the  missile’s 
designated  launch  position,  and  the  initial  direction  of  flight  for  the 
missile.  This  direction  is  returned  in  both  radians  and  compass 
degrees  (Figure  7.1). 

None. 


Description:  Prelauneh  first  provides  three  screens  of  introductory  information. 

Each  screen  is  an  object  defined  by  makeecrecn*.  After  those,  the 
user  is  presented  with  a  full  screen  contour  map  of  the  ten 
kilometer  by  ten  kilometer  area  available  for  overflight.  Mouse- 
selected  points  define  the  missile’s  initial  position  and  direction  of 
flight,  and  are  displayed  on  top  of  the  map.  The  map  is  writemask 
protected,  so  it  is  only  drawn  twice  (once  for  each  buffer)  even 
though  the  flight  path  is  repeatedly  drawn  and  erased  on  top  of  the 
map.  The  flight  path  is  made  to  act  like  a  rubber  band  between 
the  launch  and  cursor  positions  by  repeatedly  editing  of  the 
positions  in  the  object  containing  the  flight  path  line  drawing 
commands.  Once  the  flight  path  is  confirmed,  the  launch  position 
and  heading  are  returned  to  the  fogm  program. 
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RANDNUM.  C 

Input:  Randnum  uses  the  global  random  number  seed. 

Output:  Randnxim  returns  a  floating  point  random  number. 

Side  Effects:  The  global  seed  value  used  by  randnum  is  updated  during  every 
invocation. 

Description:  Randnum  is  a  linear  congruential  pseudo-random  number 
generator.  The  algorithm  is  a  modified  version  of  the  one  given  by 
Sedgewick  [Ref.  13].  It  uses  a  a  special  piecewise  multiplication 
routine  mult  to  preserve  the  low-order  digits  of  the  newly 
generated  seed  even  in  case  of  overflow.  The  value  returned  is  the 
new  seed,  scaled  to  fall  between  zero  and  one,  inclusive.  The 
random  numbers  are  used  in  fogm  to  vary  the  point  on  the  tank 
that  the  missile  aims  for.  This  simulates  the  variance  in  impact 
point  that  results  from  the  optical  homing  of  the  real  missile. 

RANDSEED.C 

Input:  Randseed  takes  a  long  integer  as  input. 

Output:  None. 

Side  Effects:  Randseed  updates  the  global  random  number  seed  value. 

Description:  The  pseudo-random  number  generator  implemented  in  randnum 

always  returns  the  same  string  of  numbers  when  it  starts  with  a 
given  seed  value.  Randseed  provides  the  means  to  change  that 
initial  seed  value  so  that  different  program  runs  will  have  different 
strings  of  “random”  numbers. 

READCONTROLS.C 

Input:  The  inputs  to  readeontrols  are  the  global  X,Y ,  and  Z  random 

offset  values  for  the  aim  point  on  the  target,  the  current 
designate/reject  status,  and  the  black-and-white  versus  color 
boolean  greyscale. 

Output:  All  of  the  user-commanded  control  values  are  output  from 

readeontrols :  missile  speed,  heading  and  altitude,  camera  pan,  tilt, 
and  zoom  angles,  plus  designate/reject  status,  greyscale  status. 
Readeontrols  also  returns  values  for  the  booleans  that  control  the 
active  and  flying  loops. 

Side  Effects:  When  a  target  is  first  designated,  readeontrols  calls  randnum  and 
updates  the  global  target  aim  offsets  randz ,  randy ,  and  randz. 


Description:  Readeontroh  checks  the  status  of  all  of  the  valuators  that  provide 

input  to  the  FOG-M  simulator,  and  performs  scaling,  units 
conversion,  and  immediate  processing,  as  appropriate.  It 
determines  whether  to  accept  or  reject  a  “designate”  command, 
based  on  the  color  index  of  the  pixel  at  the  center  of  the  screen.  (If 
a  tank  is  in  the  crosshairs,  the  color  index  will  be  from  the  tank’s 
color  ramp,  and  a  designate  command  will  be  accepted.  Otherwise, 
a  designate  command  will  be  ignored.) 

READDATA.C 

Input:  None. 

Output:  None. 

Side  Effects:  Readdata  fills  the  global  array  gridpixel. 

Description:  Readdata  opens  and  reads  the  values  from  the  terrain  elevation 

data  file  and  stores  the  values  in  the  gridpixel  array.  Note  that  the 
elevation  data  file  is  arranged  in  a  format  as  discussed  in  Chapter 
III.  The  gridpixel  array  is  arranged  in  straight  rows  and  columns 
analogous  to  the  geographic  positions  of  the  data. 

ROAD  BOUNDS.C 

Input:  Road  bounds  takes  as  input  the  following: 

-  Three  arrays  (pfl,  pt2  and  pt 3)  containing  the  X  and  Z 
coordinates  of  three  points  along  the  centerline  of  the  road.  The 
line  segment  from  pt  1  to  pt 2  defines  the  first  segment  of  the  road. 
The  segment  from  pt  2  to  pt  3  defines  the  next  segment  of  the  road. 

-  A  float,  width,  which  is  the  width  of  the  road  in  feet. 

Output:  Roadbounds  returns  the  following  as  outputs:  -  Four  arrays 

[left  pt  1,  right  pt  1,  left  pt 2,  and  right  pt 2)  which  contain  the  X 
and  Z  coordinates  of  the  first  segment’s  left  and  right  sides.  The 
left  side  runs  from  left  pt  1  to  left  pt  2  and  the  right  side  runs  from 
right _ptl  to  right _pt2. 

-  Four  integers,  first  xgrid,  first  zgrid,  last  xgrid  and  last  zgrid, 
which  are  the  indices  of  the  bounding  box  surrounding  the  first 
road  segment  (see  Figure  8.2). 

Side  Effects:  None. 

Description:  Given  three  points  along  the  center  line  of  the  road,  and  the  road’s 
width,  road  bounds  computes  the  start  and  end  coordinates  for  the 
first  segment’s  left  and  right  sides.  The  end  coordinates  are 
computed  as  the  intersection  of  the  first  segment’s  left  (or  right) 


side  with  the  second  segment’s  left  (or  right)  side.  This  insures 
that  adjoining  segments  will  meet  cleanly.  The  second  function  of 
road_bounds  is  to  compute  a  bounding  box  around  the  first  road 
segment.  This  box  is  defined  as  the  row  indices  of  the  northern 
and  southern  most  gridsquares  that  the  road  segment  intersects, 
and  the  column  indices  of  the  eastern  and  western  most  gridsquares 
that  the  road  segment  intersects  (See  Chapter  VIII  for  a  more 
detailed  discussion). 

SORT  ARRAY.C 

Input:  Sort  _ar  ray  takes  as  inputs: 

-  An  array  of  points,  pnts. 

-  An  integer  that  is  the  number  of  entries  in  the  pnts  array. 

-  A  boolean,  which  is  TRUE  if  the  array  should  be  sorted  in 
descending  order,  FALSE  if  the  array  should  be  sorted  in  ascending 
order. 

-  The  index  number  of  the  coordinate  that  is  the  sort  key:  0  for  the 
X  coordinate,  1  for  the  Y  coordinate,  and  2  for  the  Z  coordinate. 

Output:  Sort  array  returns  the  array  pnts  with  the  points  sorted  according 

to  the  input  parameters. 

Side  Effects:  None. 

Description:  Sort  array  performs  a  simple  "bubble-sort"  of  the  input  points 

according  to  the  input  parameters. 

UP  LOOK  POS.C 

Input:  Up  look  pos  takes  the  following  as  inputs: 

-  The  heading  of  the  missile  in  radians. 

-  The  pan  angle  of  the  camera  in  radians. 

-  The  tilt  angle  of  the  camera  in  radians. 

-  The  X ,  Y,  and  Z  coordinates  of  the  missile’s  position. 

-  The  X ,  Y,  and  Z  coordinates  of  the  locked-on  target  (if  any). 

-  A  boolean  which  is  TRUE  if  the  missile  is  locked-on  a  target, 
FALSE  otherwise. 

Output:  Up  look  pos  returns  as  outputs  the  X ,  Y ,  and  Z  coordinates  of  the 

camera’s  look-at  position. 

Side  Effects:  None. 

Description:  Up  look  position  computes  a  point  along  the  camera’s  line  of 

sight.  If  the  missile  is  locked  on  a  target,  the  look-at  position  is  the 
locked-on  target’s  position.  Otherwise  it  is  any  point  along  the 


camera’s  line  of  sight.  See  Chapter  VI  and  Figure  6.2  for  a  more 
detailed  discussion. 

UP  MSL  POSIT.C 

Input:  Upjnslposit  takes  as  inputs: 

-  The  heading  of  the  missile  in  radians. 

-  The  speed  of  the  missile  in  knots. 

-  The  X,  Y ,  and  Z  coordinates  of  the  missile’s  position. 

-  The  X,  K,  and  Z  coordinates  of  the  locked-on  target  (if  any). 

-  A  boolean  which  is  TRUE  if  the  missile  is  locked-on  a  target, 
FALSE  otherwise. 

Output:  Upmalpoait  returns  as  outputs: 

-  The  new  heading  of  the  missile  in  radians,  if  it  was  changed  to 
track  a  locked-on  target. 

-  The  new  heading  of  the  missile  in  degrees  measured  in  the 
compass  convention. 

-  A  boolean  which  is  TRUE  if  the  missile  is  still  flying  (has  not  hit 
a  target),  and  FALSE  if  the  missile  has  hit  the  target. 

Side  Effects:  None. 

Description:  Up  rnsl  posit  calculates  a  new  missile  position  for  the  next  frame. 

The  new  position  is  either  based  on  the  commanded  direction, 
speed,  and  altitude  (when  the  missile  is  NOT  locked  onto  a  target), 
or  the  commanded  speed  and  the  direction  to  the  target  (if  the 
missile  is  locked  onto  a  target).  For  a  detailed  discussion  of  the 
routine,  see  Chapter  VI. 

VIEW  BOUNDS. C 

Input:  View  bounds  takes  as  inputs  the  X,  Y ,  and  Z  coordinates  of  the 

missile’s  position;  the  X,  Y,  and  Z  coordinates  of  the  camera’s 
look-at  position;  and  the  field  of  view  (zoom)  value. 

Output:  View  bounds  returns  as  outputs  the  row  indices  of  the  northern 

and  southern  most  gridsquares  to  be  drawn,  and  the  column 
indices  of  the  western  and  eastern  most  gridsquares  to  be  drawn. 

Side  Effects:  None. 

Description:  The  purpose  of  view  bounds  is  to  construct  a  bounding  box  around 

the  gridsquares  which  are  to  be  drawn.  The  box  is  constructed  by 
extending  the  line  of  sight  vector  down  until  it  intersects  the 
minimum  elevation  plane.  The  view  bounds  extends  20 
gridsquares  north,  south,  east,  and  west  of  this  intersection  point. 


If  the  missile’s  position  is  not  within  the  bounds,  the  bounds  are 
extended  to  include  the  missile’s  position.  For  a  more  detailed 
discussion,  see  Chapter  VI  and  Figure  6.5 


APPENDIX  B  -  SOURCE  LISTINGS 


BUILD  ROAD 


^include  "stdio.h" 

#  include  "fogm.h" 

#  include  "files. h" 

# include  "gl.h" 

# include  "math.h" 

#define X  0 
^define  Y  1 
#define  Z  2 

fdefine  DIAGONAL  0 
fdefine  HORIZONTAL  1 
# define  VERTICAL  2 

#define  LOWER  0 
fdefine  UPPER  1 

build  road() 

{ 

extern  Object  road|99]|99|; 
extern  short  gridpixel(l00j(100j; 

FILE  *fp.  *fopen(); 

float  road  width;  /*  road  width  if  feet  */ 

int  num  pts;  /*  number  of  data  points 

for  the  road  seqment  */ 

int  segnum  =  0; 
char  tempi  100]; 
int  cnt,  i,  j; 

int  vertexcnt,  num  duplicates; 
float  gnd  level(); 
float  elev; 

float  pt  1  [ 3 1 ,  pt2|3|,  pt3|3|; 

float  nw_corner|3],  ne_corner|3|,  sw_corner|3],  se_corner|3]; 
float  right _pt  1  [3| ,  right_pt2|3|; 
float  left_ptl|3|,  Ieft_pt2(3|; 

float  north  bound,  south_bound,  eastbound,  west  bound; 
float  delta  x,  delta  s; 
float  seg  dir; 

int  ne  flag,  nw  flag,  se  Dag,  swflag; 
int  xgrid,  sgrid; 

int  first  xgrid,  last  xgrid,  firstsgrid,  lastsgrid; 
float  poly  1  [ I0|  |3|; 

frontbuffer(TRUE); 

fp  =  fopen(ROAD  FILE/V'); 


while  (fscanf(fp,  "%e",  fcroadwidth)  !=  EOF)  { 
fscanf(fp,  "%d",  Jinumpts); 
fscanf(fp,  "%e  %e",  fcptl|X|,  tptl|Zl); 
fscanf(fp,  ”%t  %t'\  fcpt2(X|,  fcpt2|Z|); 

delta _x  =  pt2|X|  -  pt  1 1 X ] ; 
deltas  —  pt2(Z)  -  pt  1  [Z] ; 
segdir  =  atan2(delta_s,  deltax); 

left  _ptl|X|  =  ptl|X)  +  (cos(seg_dir  +  HALFPI)*road_width/2.0); 
right _pt  1  [ X j  =  ptl|X|  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
left  ptl[Zj  =  ptl(Zj  +  (sin(seg_dir  +  HALFPI)*road_width/2.0); 
right _pt  1 1 Z )  =  ptljZ]  +  (ein(»eg_dir  -  HALFPI)  *  road_width/2.0); 
for  (cnt  =  3;  cnt  <=  num_pt»  +  1;  +  +cnt)  { 
if  (cnt  <=  numpts)  { 

fscanfffp,  "%e  %e",  fcpt3|X),  lcptS[Z|); 

} 

else  { 

ptSlX]  =  pt2|X); 
ptsjz]  =  pt2{Zj; 

} 

/*  print  new  road  segment  number  on  title  screen  */ 

segnum  +=1; 

pushmatrixQ; 

ortho2(0.0,  1023.0,  0  0,  767.0); 
viewport  (0, 1023, 0,767); 

sprintf(temp,  "Building  road  segment:  %d%",  segnum); 
color  (BLUE); 

rectf(780.0,  20.0,  1010.0,  30.0); 

color(CYAN); 

cmov2i(780,  20); 

charstr(temp); 

popmatrix(); 

/*  determine  the  boundaries  of  this  road  segment  */ 
road  bounds (ptl,  pt2,  pt3,  road  width,  leftptl,  rightptl, 
left_pt2,  right  pt2,  &  first  xgrid, 

&first_sgrid,  tlastxgrid,  Alast  sgrid); 

for  (xgrid  =  first  xgrid;  xgrid  <=  last  xgrid;  ++xgrid){ 

for  (sgrid  =  first  igrid;  igrid  <=  last  xgrid;  ++sgrid){ 
neflag  =  FALSE; 
nwflag  -  FALSE; 
sw  flag  =  FALSE; 
se  flag  =  FALSE; 
vertex  cnt  =  -1; 

east  bound  =  (fioat)(xgrid  +  1)  *  FT_100M; 
west  bound  =  (floatj(xgrid)  *  FT100M; 
north _bound  =  (float) (sgrid  +  1)  *  FT_100M; 
south  bound  =  (floatj(sgrid)  *  FT100M; 

sw  cornerjXj  =  west_bound; 
sw_corner|Z)  =  southbound; 
elev  =  gridpixel|sgrid]|xgrid)  ti  elev  mask; 
sw  cornerjY)  =  pow(elev,  ALTSCALE); 
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se_corner|X|  =  eut  bound; 

se_corner(Z|  =  southbound; 

eiev  =  gridpixel|sgrid]|xgrid-t-l|  It  eiev  mask; 

se_corner(Y)  -  pow  (eiev,  ALTSC  ALE); 

nw_coruer|X)  =  westbound; 
nw_cornerjZ)  =  northbound; 
eiev  =  gridpixe!jsgrid+lj[xgrid|  It  elevmask; 
nweornerjY]  =  pow(elev,ALTSCALE); 

necornerjXJ  =  eastbound; 

necorner|Z]  =  northbound; 

eiev  =  gridpixel|sgrid+l][xgrid  +  l)  It  elevmask; 

ne_corner[Yj  =  pow(elev,  ALTSCALE); 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  eastern  grid  boundary 
and  add  these  points  to  the  polygon  vertex  array  */ 

do_boundary(VERTICAL,  UPPER,  xgrid,  igrid,  secorner,  necorner, 
left _pt  1 ,  left  pt2,  right  ptl,  right  pt2,  Itse  flag, 

Itneflag,  polyl,  It  vertex  cnt); 

j*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  northern  grid  boundary 
and  insert  these  points  into  the  polygon  vertex  array  */ 
do  boundary  (HORIZONTAL,  UPPER,  xgrid,  sgrid,  necorner, 
nw  corner,  left  ptl,  left_pt2,  right  ptl, 
right  pt2,  Itne  flag,  Itnw  flag,  polyl,  Itvertex  cnt); 

/  *  determine  points  of  intersection  between  the  left  and 
right  sides  of  the  road  and  the  diagonal  and 
insert  these  pointsinto  the  polygon  vertex  array  */ 

do_boundary(DIAGONAL,  UPPER,  xgrid,  sgrid,  nw  corner,  se  corner, 
left  ptl,  left  pt2,  right  ptl,  right  pt2,  fcnw  flag, 

Itse  flag,  polyl,  k vertex  cnt); 

/*  remove  duplicate  entries  from  the  polygon  array  */ 

numduplieates  =  0; 

for  (i  =  1;  i  <=  vertex  cnt;  -t-+i)  { 

if  ((poly l(i]|0j  ==  polyl|i-lj[0|)  kk 
(polyl(i]|2|  ==  poly  1  (>- 1  )f 2}))  { 

for  (j  =  i;  j  <  vertex  _ent  -  num  duplicates;  +  +j)  { 

poly  i{j)l°l  =  p<>iyiU+i||o|; 
poly  i  U)  [  1 1  =  poiy»li+i|[ij; 

polylljji2|  =  polylU+lj|2|; 

} 

num  duplicates  +=  1; 

} 

} 

vertex  cnt  -=  num  duplicates; 

ISO 
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if  (vertexcnt  >  0)  {  /*  add  polygon  to  grid  object  */ 
if  (road(sgrid|(xgridj  !=  0)  { 

editobj(rond|igrid|  [xgrid  |); 

} 

else  { 

road|sgrid]|xgrid]  =  genobjQ; 
m  nkeo  b j  ( rood  |  igrid  { j  xgr  id  | ) ; 

} 

color(ROADGREY); 

polf(vertex  cnt  +1,  ltpolyl|0||0]); 

linewidth(S); 

poly  (vertex  cnt  +  1,  itpolyl|0j|0j); 
closeobj(); 

} 

vertexcnt  =  -1; 
neflag  =  FALSE; 
aw  ling  =  FALSE; 
sw  flag  =  FALSE; 
ae  flag  =  FALSE; 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  rood  and  the  southern  grid  boundary 
and  insert  these  points  into  the  polgon  vertex  array  */ 
doboundary (HORIZONTAL,  LOWER,  xgrid,  sgrid,  sw  comer, 
secorner,  leftptl,  !eft_pt2,  right  ptl, 
rightptl,  icswflag,  fcseflag,  polyl,  ti vertex  cnt); 

/*  determine  points  of  intersection  between  the  left  and 
right  sides  of  the  road  and  the  diagonal  and 
add  these  points  to  the  polygon  vertex  array  */ 

do  boundary(DIAGONAL,  LOWER,  xgrid,  sgrid,  se  corner,  nwcorner, 
left  ptl,  left  j>t2,  rightptl,  right  pt2,  &se  flag, 

Icnw  flag,  polyl,  fcvertexcnt); 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  western  grid  bound 
and  add  these  points  to  the  polygon  vertex  array  */ 

do_boundary(VERTICAL,  LOWER,  xgrid,  sgrid,  nw  corner,  sw  corner, 
left  ptl,  left_pt2,  right  ptl,  right  pt2,  Inw  flag, 
ieswflag,  polyl,  fcvertexcnt); 

/*  remove  duplicate  entries  from  the  polygon  array  */ 

num  duplicates  =  0; 

for  (i  =  1;  i  <=  vertex  cnt;  +  +  i)  { 

if  ((poly l{i](0}  ==  polyl[i-l]j0])  LL 
(poly  11*112)  *=  polylji-l)l2)))  { 

for  (j  =  i;  j  <  vertex  cnt  -  num  duplicates;  ++j)  { 
poly  1 U1 10]  =  polyl(j+l)|0|; 
poly  l(j!(l  I  =  poly  l(j-ni(ll; 
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polyi|j)j2|  =  poly![j+I)|2]; 


} 

num  duplicates  +  -  1, 

} 

} 

vertex cnt  -=  num  duplicates; 

if  (vertex_cut  >  0)  {  /*  add  polygon  to  grid_object  */ 
if  (road|sgrid)|xgrid|  !=  0)  { 

editobj  (road  |  sgrid]  (xfrid  | ) ; 

} 

else  { 

road  |  sgrid  1 1  xgr  id  J  =  genobj(); 
makeobj  ( road  [  sgrid  |  (xgrid  | ) ; 

} 

color(ROADGREY); 

polf(vertex  cnt  +1,  Itpoly  lj0]|0]); 

linewkUh(S); 

poly  (vertex  cnt  +  I,  itpoly  1|0]|0|); 
cloeeobj(); 

} 

} 

} 

right _ptl|X]  =  right  pt2|X|; 
right  _ptl|Z|  =  right  _pt2|Zj; 
left  ptI|X|  =  left  pt2jX|; 
left  pt  1  [Zj  =  left _ pt2 [ Z| ; 

ptI[X(  =  pt2(X|; 
ptl|Z|  =  Pt2|Z|; 

Pt2|X)  =  ptSjXl; 

Pt2[Z)  =  ptS|Z|; 

} 

} 

fclose(fp); 

frontbulfer(FALSE); 


} 


BUUDTEHJLAIN 


/*  buildterrain.c  -  this  function  builds  objects  representing  1km  grid  squnres 
in  3-D,  with  euck  grid  squnre  genernting  4  objects,  identical  except  for 
order  of  drawing  */ 

4  include  "gl.h"  /*  get  the  graphics  defs  */ 
f  include  "device. k"  /*  get  the  graphics  device  defs  */ 

# include  "fogm.h"  /*  default  constants  */ 

{include  "math.h"  /*  math  function  declarations  */ 

buildtcrrainO 

{ 

/*  array  of  data  points  to  build  the  terrain  */ 
extern  short  gridpixeljlOOjjlOOj; 

extern  float  savetrianglej99]|99]|2j|3j|Sj; 

extern  long  gridcolor|99j|99]; 

extern  Object  target  (99|(99|; 

extern  float  ground_plane(4j[3|; 

extern  long  gnd  plane  eolor; 

float  gnd  plane  _ht; 

Coord  trianglel|3||3j,  triangle2(3||3);  /*  polygon  coordinates  */ 

short  xgrid,  sgrid;  /*  indexes  into  the  grid  object  array  */ 

short  end  row,  endcol;  /*  miscellaneous  indexes  etc  */ 

int  row,  col; 

float  ax, ay, as;  /*  interior  point  for  use  in  the  lightpoly  function  */ 

float  lx,ly,ls;  /*  position  of  light  source  in  lightpoly  function  */ 

/*  min  and  max  colormap  indexes  for  lighting  the  poly  */ 
long  colormin,  coiormax; 

/*  color  index  to  use  returned  by  the  lightpoly  function  */ 
long  colortouse,  color  1,  color2. 

char  temp(50|;  /*  character  string  for  countdown  */ 

float  x,y; 
float  gammacorr; 

long  rampamax,  rampamin,  rampbmax,  rampbmin; 
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int  start  row,  startcol,  coordidx,  vertex; 


lx  =  500  *  FT100M;  /*  direction  of  light  source  */ 

ly  =  100000  *  FT  100M, 

1»  =  ly; 

firontbuffer(TRUE);  /*  write  to  front  buffer  */ 

/*  compute  color  for  ground  plane  polygon  */ 

gnd  plane  _ht  =  pow(( float) MIN,  ALTSCALE); 

ground _plane|0||0|  =  -NUMXGRIDS  *  FEETPERGRID; 

ground  plane|0]|l)  =  gnd_plane_ht; 

ground  ~plane(0j[2|  =  NUMZGRIDS  *  FEETPERGRID; 

ground  plane] l]|0j  =  *-0  *  NUMXGRIDS  *  FEETPERGRID; 

ground  _plane(lj[l|  =  gndplaneht; 

ground "pl»ne|l)|2!  =  NUMZGRIDS  *  FEETPERGRID; 

ground  planei2l!0|  =  2.0  *  NUMXGRIDS  *  FEETPERGRID; 
ground _plane|2]{l]  =  gnd  plane  ht; 

ground  plane|2]|2!  =  -2.0  *  NUMZGRIDS  *  FEETPERGRID; 

ground  plane[3j!0|  =  -NUMXGRIDS  *  FEETPERGRID; 
ground_plane|3|[lj  =  gnd  plane  ht; 

ground  Plane|3||2|  =  -2.0  *  NUMZGRIDS  *  FEETPERGRID; 

lightorient(ground_plane, 4, 0.0, 0.0, 0.0, lx, ly ,1s, 256,461,  Agnd  plane  color); 

/*  compute  coordinates  and  colors  for  triangles  and  store  in  global 
variable  savetriangle  for  later  display  */ 

for  (col  =  0;  col  <  99;  ++col)  { 

/*  print  new  countdown  number  on  title  screen  */ 
pushmatrixQ; 

ortho2(0  0,  1023.0,  0.0,  767.0); 
viewport(0, 1023,0,767); 

sprintf(temp,  "Countdown  to  launch:  %d%",  98  •  col); 
color(BLUE); 

rectf(780.0,  15.0,  1010.0,  30.0); 

color(CYAN); 

cmov2i(788,  20); 

charstr(temp); 

popmatrix(); 

for  (row  =  0;  row  <  99;  +  +  row )  { 

/*  choose  which  color  ramp  to  use  so  that  a  checker  board 
effect  is  acheived  * / 
if  ((row+col)%2){ 

colormin  =  256; 
colormax  =  461; 


colormin  =  402; 
colormax  =  007; 

} 

/*  build  the  polygon  */ 

triangle  1(0) 1 2|  =  (float) row  *  (-41.01)  *  8.0; 

trianglel(0|(0|  =  ( float )col  *  41.01  *  8.0; 

trianglel(0|(lj  =  pow  ((float)  (grid  pLxel(row](col|telev_ma»k) 

,  ALTSCALE); 

trianglel(lj(2]  =  (float) row  *  (-41.01)  *  8.0; 
triangleljljjo]  =  ( float )(col+l)  *  41.01  *  8.0; 
trianglel[lj[lj  =  pow((float)(gridpixel[row)[col+l|&elev_mask) 
.ALTSCALE); 

trianglel|2]|2]  =  ( float )( row +  l)  *  (-41.01)  *  8.0; 
trianglel(2|joj  =  (float)eol  *  41-01  *  8.0; 

trianglelj2)(l]  =  pow((float)(gridpixel[row+lj[eol]&elev_mask) 

.ALTSCALE); 

/*  copy  common  vertex  values  for  opposing  triangle  of  grid  */ 
for  (vertex  =  1;  vertex  <  3;  +  -(-vertex)  { 

triangle2|vertex][0]  =  trianglel|vertexj|0]; 
triangle2[  vertex]  (1  j  =  triangle  1  ( vertex  j  ( 1  j ; 
triangle2jvertexj(2]  =  trianglel|vertex]|2); 

} 

j*  change  corner  coordinate  to  form  opposing  triangle  of  grid  */ 
triangle2[0]|2]  =  ( float )( row +  l)  *  (-41.01)  *  8.0; 
triang]e2[0j(0j  =  (float) (col-t-1)  *  41.01  *  8.0; 
triangle2[0j(l)  =  pow((float)(gridpixel|row+l)[eol+l)fcelev_mask) 

,  ALTSCALE)  ; 

/*  compute  an  interior  point  for  triangle  1  */ 
ax  =  triangle  1(0)  (0]  +  15.0; 
ay  =  -10.0; 

as  =  trianglel (0|(2j  -15.0; 
j*  light  and  orient  trianglel  */ 

lightorient(trianglel,3,ax,ay,as,lx,ly,ls,colormin,  colormax,  tcolorl); 

j*  compute  interior  point  for  triangle2  */ 
ax  =  triangle2|0j|0j  -  15.0; 
ay  =  -10.0; 

as  =  triangie2(0]|2]  +15.0; 

/*  compute  the  light  for  and  orient  triangle2  */ 
lightorient(triangle2, 3, ax, ay, as, lx, ly, Is, colormin, colormax,  &color2); 


/*  compute  average  color  for  the  square  *  j 


colortouse  =  (color  1  +  color!)  /  2; 


/*  save  this  triangles  color  and  orientation  */ 
for  (vertex  =■  0;  vertex  <  3;  ++ vertex) 

for  (coordidx  =  0;  coordidx  <  3;  ++coordidx)  { 
savetriangle[row]  (col]  [0|  [vertex]  (coordidx)  = 
trianglel  |vertex]  (coordidx); 
savetrianglejrowj(colj(l][vertex]  jcoordidx]  = 
triangle2  [vertex]  (coordidx] ; 

} 

gridcoiorjrowjjcolj  =  colortouse; 


frontbuffer(F  ALSE) ; 


COLORRAMP 


/*  constructs  the  color  ramps  to  be  used  for  displaying  the  terrain. 

If  greyscale  is  true,  constructs  greyscale  ramps,  else  it 
constructs  green  ramps.  */ 

#include  "fogm.h"  /*  fogm  constants  */ 

colorramp(greyscale,init) 
int  greyscale,  init; 

{ 

int  i; 

/*  build  two  gamma  corrected  color  ramps  with  slightly  offset  colors  */ 
if  (greyscale)  { 

gammaramp(1.5,256,205,255,255,255,50,50,50);  /*  even  terrain  ramp  */ 
gammaramp(1.5,462,205,245,245,245,40,40,40);  /*  odd  terrain  ramp  */ 
gammaramp(1.5,668,180,235,235,235,S0,30,S0);  /*  tank  ramp  */ 
mapcolor(SKYBLUE,230,230,230);  /*  sky  color  */ 

mapcolor(ROADGREY,35,35,35); 

} 

else  { 

gammaramp(l. 5, 256, 205, 0,255, 0,0, 50,0);  /*  even  terrain  ramp  * / 

gammarampj  1.5, 462, 205, 0,245, 0,0, 40,0);  /*  odd  terrain  ramp  */ 

gammaramp(1.5,668,180,255,165,55,75,55,0);  /*  tank  ramp  * / 

mapcolor(SKYBLUE,200, 200,255);  /*  sky  color  */ 

mapcolor(ROADGREY,35,35,S5); 


if  (init)  { 

mapcolor(  16,0,70,0);  /*  set  up  colors  for  contour  map  */ 

mapcolor(  17, 0,80,0); 

mapcolor(  18,0,90,0); 

mapcolor(19,0,100,0); 

mapcolor(20,0, 1 10,0) ; 

mapcolorj  21 ,0, 120,0), 

mapcolor(22, 0,1 30,0); 

mapcolor(2S,0, 1 40,0); 

mapcolor(24 ,0,1 50,0); 

mapcolor(25,0,165,0); 

mapcolor(26, 0,180,0); 

mapcolor(27,0, 190,0); 

mapcolor(28, 0,2 10,0); 

mapcolor(29,0,225,0); 

mapcolor(30, 0,240,0) ; 

mapcolor(31, 0,255,0); 

mapcolor(32,75,55,0); 

mapcolor(33,95,60,0); 

mapcolor(34, 115,70,0); 

mapcolor(35, 125,70,0); 
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mapcolor(36, 135,83,0); 

mapcolor(S7, 145,90,0); 

mapcolorj 38, 155,97,0); 

mapcolor  ( 39, 165 , 105 ,0) ; 

mapcolor(40, 175, 110,0); 

mapcolor(41, 185, 113,0)', 

mapcolor(42, 190, 118,0); 

mapcolor(43,200, 127 ,0) ; 

mapcolor(44, 210, 135,30); 

mapcolor(45, 225, 145,35); 

mapcolor(46, 240, 155,45); 

mapcoior(47, 255, 165,55); 

for  (i=64;  i<  128;  i++)  mapcolor(i,0,0,255); 

for  (i=128;  i<256;  i++)  mapcolor(i,255,0,0); 

mapcolor(851, 0,150,0);  /*  set  up  colors  for  instruction  box  * / 

mapcolor(852, 255, 165,55); 
mapcolor(853 ,95,60,0); 

mapcolor(854, 0,0,0);  /*  color  for  indicator  box  background*/ 


COMPASS 


/*  compute  the  compass  heading  in  degrees  of  the  input  direction.  */ 

#include  "fogm.h"  /*  fogm  constants  */ 

float  compass(direction) 
double  direction; 

{ 

float  compassdir; 

compassdir  =  RTOD  *  direction; 
if  (compassdir  <=  90.0) 

compassdir  =  90.0  -  compassdir; 

else 

compassdir  =  450.0  •  compassdir; 
return  (compassdir) ; 

} 
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DISPLAY  TERRAIN 


/*  Compute  which  polygons  need  to  be  drawn  to  display  the  terrain  and 
output  them  in  an  order  such  that  the  polygons  farthest  from  the  viewer 
are  drawn  first  and  those  closest  are  drawn  last. 

Note:  Eventhough  this  seems  like  a  long  routine,  it  is  broken  into  8 
independent  cases  based  on  the  direction  the  camera  is  looking. 

If  you  understand  <  ne  case  the  others  are  merely  mirror  images  of  the 
algorighm  for  other  octants.  */ 

if  include  "fogm.h" 

^include  "math.h" 

#  include  "gl.h" 

display _terrain(vx,  vy,  vs,  px,  py,  ps,  fovy, 
firstxgrid,  firstsgrid,  lastxgrid,  lastsgrid) 

Coord  vx,  vy,  vs,  px,  py,  ps; 
int  fovy; 

short  firstxgrid,  firstsgrid,  lastxgrid,  lastsgrid; 

{ 

extern  float  ground_plane|4]|Sj; 

extern  long  gnd  plane  color; 

extern  Object  road|99]|99(; 

extern  Object  target (99]  (99]; 

extern  float  savetriangle[99]|99)(2](3]j3|; 

extern  long  gridcolor]99][99]; 

double  lookdir; 

int  threshold,  count,  startx,  starts; 
short  xgrid,  sgrid; 
float  tanval; 
float  y; 

if  (TV)  viewport(0, 474, 0,474); 
else  viewport(0, 787, 0,767); 
pushmatrix(); 

color(SKYBLUE); 

clear(); 

ortho2(0  0, 1023.0, 0.0, 767.0);  /*  outline  the  screen  */ 

color(BLACK); 

recti(0, 0,1023,767); 

popmatrixQ; 

pushmatrixQ; 

perspective(fovy,  1.0,0.0,19500.0); 
lookat(vx,vy,vs,px,py,ps,0.0); 


/*  determine  the  direction  of  the  line  of  sight  */ 
lookdir  =  (double)atan2(  (float)  (vs  •  pi),  (float)(-(vx  •  px))); 
if  (lookdir  <  0.0)  lookdir  +=  TWOPI; 

/*  lay  down  the  ground  plane  */ 
color(gndplanecolor); 
polf(4,  ground  _plane); 

/*  put  the  grid  objects  through  the  geometry  engine  in  an  order 
based  on  the  lookdir.  */ 
if  (lookdir  >  SEVENQTRP1) 

{ 

/*  8th  OCTANT  */ 

threshold  =  (int)(tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 
startx  =  lastxgrid; 
starts  =  firstsgrid; 
while  (starts  <=  lastsgrid)  { 
sgrid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  kk  (sgrid  <=  lastsgrid))  { 

color(gridcolor(sgrid]  [xgrid)); 
polf(3,&savetrianglejsgrid)[xgrid]  [0]  [0]  [0|) ; 
polfjs.&savetrianglejsgridjjxgridjjljlojjoj); 

if  (road[sgrid|[xgrid)  !=  0)  callobj(road[sgrid)[xgrid]); 
if  (target [xgrid] [sgrid)  !-  0)  cal)obj(target|xgrid)[sgrid]); 

/*  check  if  tank  should  be  drawn  now  */ 

sgrid  +=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
xgrid  +=  1; 
count  =  0; 

} 

} 

startx  -=  1; 
count  =  0; 

if  (startx  <  firstxgrid)  { 
startx  -  firstxgrid; 
starts  +=  threshold; 

} 

} 

} 

else  if  {(lookdir  >  THREE  HALVES  PI)  kk  (lookdir  <=  SEVEN  QTR  PI)) 

{ 
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/*  7th  OCTANT  •/ 

tanval  —  tan(lookdir-t-HALFPI); 

if  (tanval  ==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 

count  =  0; 
startx  =  lastxgrid; 
starts  =  first  sgrid; 
while  (startx  >  =  firstxgrid)  { 
sgrid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  kk  (sgrid  >=  firstsgrid))  { 

color(gridcolor[sgrid]  [xgrid)); 
polf(3,&savetriangle[sgrid][xgrid][0][0][0]); 
polfjs.Asavetrianglejsgridjjxgridjjljjojjoj); 
if  (road[sgrid]|xgridj  !=  0)  callobj(road[sgrid][xgridj); 
if  (target[xgridj[sgridj  !=  0)  callobj(target[xgrid][sgridj); 

xgrid  -=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
sgrid  --  1; 
count  =  0; 

} 

} 


starts  +=  1; 
count  =  0; 

if  (starts  >  lastsgrid)  ( 
starts  =  lastsgrid; 
startx  -=  threshold; 

} 

} 

else  if  ((lookdir  >  FIVE  QTR  PI)  kk  (iookdir  <=  THREE  HALVES  PI)) 

{ 

/*  6th  OCTANT  */ 

tanval  =  -tan(lookdir+HALFPI); 

if  (tanval  ==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 


count  =  0; 
startx  =  firstxgrid; 
starts  =  firstsgrid; 


while  (startx  <=  lastxgrid)  { 

■grid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  kk  (igrid  >=  firstsgrid))  { 

color  (grid  color  [igrid  ]  [xgrid  ]) ; 

polf(S,&Mvetriangle[>ghd)[xgridj|0)|0)[0j); 

polf(S,icsavetriangle[sgridj[xgridjjlj[0)[oj); 

if  (road[sgrid)[xgrid]  !=  0)  callobj(road[sgrid)|xgrid)); 
if  (targetjxgridjjigridj  !=  0)  callobj(target|xgrid)|igrid)); 
xgrid  +=  1; 
count  +=  1; 

if  (count  >  =  threshold).  { 
sgrid  -=  1; 
count  =  0; 

} 


starts  +=  1; 
count  =  0; 

if  (starts  >  lastsgrid)  { 
starts  =  lastsgrid; 
startx  +  =  threshold; 

} 


else  if  ((lookdir  >  PI)  kk  (lookdir  <=  FIVEQTRP1)) 

{ 

/*  5th  OCTANT  */ 

threshold  =  (int)(-tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 
startx  =  first  xgrid; 
starts  =  first  sgrid; 
while  (starts  <=  lastsgrid)  { 
sgrid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  kk  (sgrid  <  =  lastsgrid))  { 
color(gridcolor[sgrid  [[xgrid]); 
polf(S,&savetriangle(sgrid)[xgrid|[0)[0j[0)); 
polf(5,  id  savetriangle  [sgrid  j  [xgrid  j  |  lj(0]  [0] ) ; 

if  (road[sgridj[xgrid|  !=  0)  callobj(road[sgrid]|xgrid]); 
if  (target[xgridj|sgrid[  !=  0)  callobj(target|xgrid|[sgrid[); 
sgrid  +=  1; 
count  +=  1; 
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if  (count  >=  threshold)  { 
xgrid  -=  1; 
count  =  0; 

} 

> 


startx  +=  1; 
count  =  0; 

if  (sturtx  >  last  xgrid)  { 
startx  =  last  xgrid; 
starts  +=  threshold; 

} 

} 

} 

else  if  ((lookdir  >  THREE  QTR  PI)  kk  (lookdir  <  =  PI)) 

{ 

/*  4th  OCTANT  */ 

threshold  =  (int)(tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 
startx  =  firstxgrid; 
starts  =  lastsgrid; 
while  (starts  >=  firstsgrid)  { 
sgrid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  kk  (sgrid  >=  firstsgrid))  { 

color(gridcolor[sgrid||xgrid|); 
polf(3,&8avetriangle(sgridjjxgridjf0j(0j{0j); 
polfjs.Atsavetrianglejsgridjjxgridjjljjojjoj); 
if  (road|sgrid] (xgrid]  !=  0)  callobj(rosd[sgridj[xgridj); 
if  (target(xgridj[sgrid)  !=  0)  callobj(target]xgrid]|sgrid]); 

sgrid  -=  1; 
count  +=  1; 

if  (count  >  =  threshold)  { 
xg<«d-=  1; 
count  =  0; 

} 

} 


startx  +=  1; 
count  =  0; 

if  (startx  >  lastxgrid)  ( 
startx  =  lastxgrid; 
starts  -=  threshold; 

} 

} 
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else  if  ((lookdir  >  HALFP1)  kk  (lookdir  <=  THREE  QTR  PI)) 

{ 

/•  3rd  OCTANT  */ 

tanval  =  twi  (lookdir +HALFPI); 

if  (tanval  ==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 

count  =  0; 
startx  =  firs  tx  grid; 
starts  =  lasts  grid; 
while  (startx  <=  lastxgrid)  { 
sgrid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  hk  (sgrid  <=  lastsgrid))  { 

color  (gridcolor  ( sgrid  j  j  xgrid] ) ; 

polf(3,&savetriangle(sgrid]{xgridj[0j[0][0]); 

polf(3,&savetriangle(sgrid](xgrid]|l]jojjoj); 

if  (road[sgridJ[xgrid]  !=  0)  callobj(road[sgrid][xgrid]); 
if  (targetlxgrid]|sgrid|  !=  0)  callobj(target|xgrid]|sgrid|); 
xgrid  +=  I; 
count  +=  1; 

if  (count  threshold)  { 
sgrid  +=  1; 
count  =  0; 

} 

} 

starts  -=  1; 
count  =  0; 

if  (starts  <  firstsgrid)  { 
starts  =  firstsgrid; 
startx  +=  threshold; 

} 

} 

} 

else  if  ((lookdir  >  QTR  PI)  kk  (lookdir  <=  HALFPI)) 

{ 

/*  2nd  OCTANT  */ 

tanval  =  -(tan(lookdir+HALFPI)); 

if  (tanval  ==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  4  0.5); 
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count  =  0; 
startx  =  last  xgrid; 

■tarts  =  lasts  grid; 

while  (startx  >=  firstxgrid)  { 

■grid  =  starts; 
xgrid  =  startx; 

while  ((sgrid  <  =  lastsgrid)  tit i  (xgrid  >—  firstxgrid))  { 

color(gridcolorjsgridjlxgrid)); 

polf(  S  ,t  savetriangle  j  sgrid )  [xgrid]  [0]  [0|  (0) ) ; 

polf ( S ,  fcsavetriangle  [  sgrid  ]  j  xgrid  jjlj|0)[oj); 

if  (road(sgridj(xgrid|  !=  0)  callobj(road(sgrid|(xgridj); 
if  (target[xgrid](sgrid|  !=  0)  callobj(target[xgrid][sgrid|); 
xgrid  -=  1; 
count  +=  1; 

if  (count  >  =  threshold)  { 
sgrid  +=1; 
count  =  0; 

} 

) 

starts  -=  1; 
count  =  0; 

if  (starts  <  first  sgrid)  { 
starts  -  firstsgrid; 
startx  -=  threshold; 

} 

} 

} 

else  if  ((lookdir  >=  0.0)  ielt  (lookdir  <=  QTR_PI)) 

{ 

/*  1st  OCTANT  */ 

threshold  =  (int)(-tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 
startx  =  last  xgrid; 

■tarts  =  lastsgrid; 
while  (starts  >  =  firstsgrid)  ( 
sgrid  =  starts; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  titi  (sgrid  >  =  firstsgrid))  { 

color(  gridcolor  [  sgrid  1 1  xgrid  ] ) ; 

polf(  3,&savetriang)ejsgrid )  [xgrid )  (0)  |0[  [0) ) ; 

polf(  S  .Acsavetrianglej  sgrid )  jxgridj  [  1  j  |0j  [0] ) ; 

if  (road|sgrid][xgridj  !=  0)  callobj(road[sgrid)[xgrid[); 


if  (target|xgrid]|sgrid]  !=  0)  caUobj(target[xgridj|sgrid)); 
•grid  •=  1; 
count  +=  1; 

if  (count  >  =  threshold)  ( 
xgrid  ■+  =  1; 
count  =  0; 

} 

} 


startx  *=  1; 
count  =  0; 

if  (startx  <  firstxgrid)  { 
•tnrtx  *  firstxgrid; 
starts  •=  threshold; 

} 

} 

} 

popmatrix(); 

} 
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D1ST  TO  LOS 


# include  "gl.h" 

#include  "muth.h" 

flout  diet  to_lo«(vx,vy,vi,px,py, pinpoint) 

/*  compute  the  diitunce  from  the  point  "point”  to  the  line  of  light  */ 

Coord  vx.vy.vi.px.py.pi; 
flout  pointjS]; 

{ 

flout  u,b,c;  /*  direction  numben  of  line  of  tight  */ 
flout  d,e,f; 
flout  diet; 

u  =  (flout)(px  -  vx); 
b  =  (flout)jpy  -  vy); 
c  =  (flout)(pi  -  vi); 

d  =  pointjOj  •  (flout)vx; 
e  =  point|l|  -  (flout)vy; 
f  =  point(2|  -  (flout)vi; 

dist  =  sqrt((up  i(e*c  -  f*b,2)  +  up_i(f*u-  d*c,2)  +  up_i(d*b  -  e*u,2))/ 
(up  i(u,2)  +  up  i(b,2)  +  up  i(c,2))); 

return  (dist); 

} 
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DO  BOUNDARY 


#  include  "gl  h" 

^include  "math.h" 
{include  "stdio.h" 
{include  "fogm.h" 

{define  X  0 
{define  Y  1 
{define  Z  2 

#define  DIAGONAL  0 
{define  HORIZONTAL  1 
#define  VERTICAL  2 

#define  LOWER  0 
{define  UPPER  1 

#define  NONE  0 

#define  INTERSECT  I 
{define  PROPER  2 


do  boundary(bound  type,  whichtriangle,  xgrid,  (grid, 
boundstart,  boundend,  leftstart, 
leftend,  right  start,  rightend,  start  corner  flag, 
end  corner  flag,  polyl,  vertexcnt) 

int  bound  type,  which  triangle,  xgrid,  igrid; 

float  bound  _start[3j,  bound_end[3],  left  start[3),  !eft_end[3], 
righ t  start [3{,  right_end[3); 

int  *start_corner_flag,  *end  corner  flag; 

float  polyl(10|(3|; 

int  ‘vertex  cnt; 


{ 

int  test  index,  cnt,  index; 

float  bound  right|3),  bound  JeftjSj,  bound_start_edge|3), 
bound  end  _edge(3|; 

float  vertex_array[10j|3|; 
float  road  polyjlOjjS); 
float  grid_poly(10||3j; 


int  intersect  cnt; 


int  intersecttype,  decendingsort; 


float  upperbound,  lowerbound; 

float  gnd_level(); 
int  in_this_poly(); 
intersect  cnt  =  -1; 

/*  compute  the  verticies  of  the  road  segment  currently 
being  worked  on  */ 
for  (index  =  0;  index  <  3;  ++index)  { 

road_poly[0]|index]  =  leftstartjindex); 
road_poly|l](indexj  =  leftendjindex); 
road  poly|2]|index)  =  rightendjindex); 
roadpoly(3|(index]  =  right_start(indexj; 

} 

/*  compute  the  verticies  of  the  grid  triangle  associated  with 
this  boundary  * / 

gridpoly  [0]  [X]  =  (float)(xgrid*FT_100M); 
grid  poly|0](Z|  =  (float)((sgrid+l)*FT_100M); 
grid  _poly  [  1  j  [  X  |  =  (float)((xgrid+l)*FT_100M); 
grid_poly|l][Z]  =  (float)(sgrid*FT_IOOM); 
if  (which  triangle  ==  UPPER)  { 

grid  poly ( 2 1 1 X )  =  (float)((xgrid+l)*FT_100M); 
grid  poly  [ 2 j  j Z ]  =  (Uoat)((sgrid+1)*FT_IOOM); 

} 

else  { 

grid_poly|2)|X|  =  (float)(xgrid*FT_100M); 
grid  poly |2||Z|  =  (float)(sgrid*FT_100M); 

} 

if  (1  ^und  type  ==  HORIZONTAL)  ( 
testindex  =  X; 

} 

else  if  (boundtype  =  =  VERTICAL)  { 
testindex  =  Z; 

} 

else  if  (bound  type  ==  DIAGONAL)  ( 
test_index  =  Z; 

} 

if  (bound  startjtest  index)  <  bound  end|test  index])  { 
lower  bound  =  bound  startjtest  index); 
upper  bound  =  boundendjtestindexj; 

} 

else  { 

lower  bound  =  bound  endjtest  index); 
upper  bound  =  bound  startjtestindex); 

» 
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/*  determine  points  of  intersection  between  left  and  right  sides 
of  the  road  and  the  boundary  */ 

line_intersect2(bound_start,  bound_end,  rightstart,  rightend, 
bound  right,  ^interseettype); 
if  (interseettype  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 
intersect  _cnt  4=  1; 

vertex_array(intersect_cnt]|X)  =  boundrightjX); 
vertex_array(intersect_cntj[ZJ  =  boundright(Z); 
vertex_array[intersect_cnt]|Y]  =  gnd_level(bound_right[X], 
-bound_right(Z|); 

} 

else  if  ((intersect  type  ==  INTERSECT)  bb 
(in  this_poly(grid_poly,  3,  rightstart))  bb 
(bound_right[test_index)  >  lower_bound)  bb 
(bound_right|test_indexj  <  upperbound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road’s  right 

line  segment,  but  the  right  start  point  is  inside  the  polygon  so 
add  the  road’s  right  start  point  to  the  vertex  array  */ 

intersect  ent  +=  1; 

vertex_array(intersect_cntj|X)  =  right  start|X); 

vertex_array[intersect_cnt](Z]  =  right_start|Z]; 

vertex  array[intersect_cnt]jY]  =  gnd  leveljright  startjX], 

-right  start JZ] ) ; 

} 

else  if  ((intersect  type  -  INTERSECT)  kb 
(in  this  poly  (grid  poly,  3,  rightend))  bb 
(bound_right[test_index|  >  lower_bound)  bb 
(bound  right|test  index)  <  upper  bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road’s  right 

line  segment,  but  the  right  end  point  is  inside  the  polygon  so 
add  the  road's  right  end  point  to  the  vertex  array  * / 

intersect_cnt  +=  1; 

vertex_array|interseet_cnt]|X|  =  right  _end|X] ; 
vertex_array|intersect_cnt]|Z!  =  right_end[Z); 
vertex_array[intersect_cntj[Y|  =  gnd_level(right_end|X), 
-right_end|Z|); 

} 

line_intersect2(bound_start,  bound_end,  left  start,  left_end, 
bound  left,  <dintersect_tyj>e); 
if  (interseet  type  ==  PROPER)  ( 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  *  / 
intersect _cnt  4=1; 

vertex_array|intersect_cnt)|X]  =  bound  _left|X|; 
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vertex  _arTay|intersectj:nt][Z|  =  bound_left[Zj; 

vertex  array [ in tersect_cnt][YJ  =  gnd_level(bound_left]X), 

-boundleftjZ]); 

} 

else  if  ( (intersect _type  -  INTERSECT)  bb 
(in_this_poly(grid_poly,  3,  leftstart))  bb 
(bound_leftjtest_index|  >  lower_bound)  bb 
( bound  Jeftj test  index )  <  upper_bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road's  left 

line  segment,  but  the  left  start  point  is  inside  the  polygon  so 
add  the  •■''ad’s  left  start  point  to  the  vertex  array  */ 

intersect  _c  *.  +=  1; 

vertex  arrayjintersect_cnt][X)  =  left_start[X); 
vertex_arrayjintersect_cnt]jZ]  =  left_start|Z|; 
vertex_array[intersect_cnt|(Y]  =  gnd_level(left_start[X), 

-left  startjZ)); 

} 

else  if  ((intersect  type  ==  INTERSECT)  bb 
(in_this_poly(grid_poly,  3,  left_end))  bb 
(bound  leftftest  index]  >  lower  bound)  Scb 
(bound  left  [test  index]  <  upper_bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road’s  left 

line  segment,  but  the  left  end  point  is  inside  the  polygon  so 
add  the  road’s  left  end  point  to  the  vertex  array  */ 

intersect  cnt  -t-=  1; 

vertex  array; intersect  cnt]|Xj  =  left  end|X|; 

vertex  array  (intersect  cnt]|Z|  =  left  endjZ]; 

vertex  array  [intersect  cnt]|Y]  =  gnd_level(left_end]X], 

-left  end  Z]); 

} 

/*  if  either  of  the  bound’s  end  points  fall  within  the  bounds  of  the 
road,  add  them  to  the  array*/ 

if  ((!*start  corner  flag)  kb  (in_this  poly (road_poly,  4,  bound _start)))  { 
/*  put  in  start  bound  point  */ 

‘start  corner  flag  =  TRUE; 
intersect  cnt  +  =  I; 

vertex  array!intersect_cnt](X|  =  bound_start[XJ; 
vertex  array! intersect  cnt] |Z]  =  bound  start|Z]; 
vertex  array'intersect_cntj|Y|  =  bound_start[Y); 

} 

if  (('*end  corner  flag)  bb  (in_this_poly(road_f>oly,  4,  bound  end)))  { 

/*  put  in  end  bound  point  */ 

‘end  corner  flag  -  TRUE; 
intersect  cnt  +•=  1; 

vertex  arrayjintersect  cnt||Xj  =  bound_end(X]; 

vertex  arrayiintersect  cnt]|Zj  =  bound_end|Z]; 

vertex  array] intersect  cnt] [ Y]  =  bound_end|Y|; 


} 

/*  determine  the  point  of  intersection  between  the  start  and  end 
bound  of  the  road  and  the  grid  boundary  */ 
line_intersect2(bound_start,  boundend,  leftstart,  rightstart, 
bound  start  edge,  fcintersecttype); 
if  (intersecttype  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 
intersect  cnt  +=  1; 

vertex_array[intersect_cnt](Xj  =  bcund_start_edge[Xl; 
vertex_array|intersect_cnt](Z)  =  bound  _start_edge|Zj; 
vertex_array(intersect_cntj(Y|  =  gnd_level(bound_start_edge[Xj, 
-bound_start_edge[Zj); 

} 

line  intersect2(bound_start,  bound  end,  left  end,  right  end, 
bound_end_edge,  &intersect_type); 
if  (intersect  type  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  *  / 
intersect_cnt  +=  1; 

vertex_array [intersect  cnt][X]  =  bound_end  edgejX]; 
vertex_array[intersect_cnt][Z]  =  bound_end_edge[Zj; 
vertexarray  [intersect  _cntj[Y]  =  gnd_level(bound_end_edge[XJ, 
-bound_end_edge[Zj); 

} 

/*  put  the  points  from  the  vertex  array  into  the  polyl  array  in 
the  proper  order  *  / 

decending  sort  =  (bound  startftest  index]  !=  lower  bound); 
sort  array (vertex_array,  intersect  cnt,  decending  sort,  test  index); 

for  (cnt  =  0;  cnt  <=  intersect  cnt;  -H-cnt)  { 

*  vertex  _cnt  +=  1; 

polyl[*vertex_cnt][X]  =  vertex_array[cnt][Xj; 
polyl[*vertex_cntj(Yj  =  vertexarrayjcntJjY); 
polyl[*vertex_cntj[Z]  =  -vertex_array|cnt)|Z]; 

} 

} 


EDIT  INDBOX 


/*  update  the  control  settings  of  the  indicator  box  */ 

#  include  "fogm.h" 

^include  "gl.h" 

edit  _indbox(indbox,  speedtag,  headingtag,  elevtag,  altmsltag, 
soomtag,  tilttag,  pantag,  desigtag,  speed,  compassdir, 
vx,  vy,  vs,  pan,  tilt,  soom,  designate) 

Object  indbox; 

Tag  speedtag,  headingtag,  elevtag,  altmsltag,  soomtag,  tilttag,  pantag, 
desigtag; 

float  speed,  compassdir; 

Coord  vx,  vy,  vs; 

double  pan,  tilt; 

int  designate; 

int  soom; 

{ 

char  chspeed[5],  chheadingjS],  chelev[5),  chaltmsl[5); 

float  gnd  level(); 

float  soomtic,  pantic,  tilttic; 

sprintf(chspeed,"%4. OT', speed);  /*  convert  speed  to  string  */ 

sprintf(chheading,"%3.0f\ compassdir);  /*  convert  heading  to  str  */ 

sprintf(chelev,"%4.0P,,vy  -  gnd_level(vx,vs));  /*  convert  elev  AGL  to  str  */ 
sprintf(chaltmsl,"%4.0r\vy);  /*  convert  alt  MSL  to  str  */ 

/*  compute  new  location  for  soom,  pan,  and  tilt  indicators  */ 

soomtic  =  soom  *  -0.2766  4  222.128; 
tilttic  =  tilt  *  721.92882  4  365.0; 
pantic  =  pan  *  -721.92682  4  435.0; 


editobj(indbox); 
objreplacef  speed  tag); 
charstr(chspeed); 
objreplace(  headingtag); 
charstr(chheading); 
objreplace(elevtag ) ; 
charstr(chelev); 
objreplace(altmsltag); 
charstr(chaltmsl); 
objreplace(soomtag); 
move2(28.0, soomtic); 
objreplace(tilttag); 


/*  update  the  indicator  display  */ 


I1#  4’*  1**  »  #, 


move2(42.0,tilttic); 

objreplace(pantag); 

move2(pantic,27.0); 

objreplace(desigtag); 

cmov2i(designate  ?  10  :  19,10); 

charstr(deaignate  ?  "DESIGNATE"  :  "REJECT"); 

closeobjQ; 


EDIT  NAVBOX 


^include  "fogm.h" 

^include  "math.h" 

# include  "gl.h" 

edit_navbox(navbox,  arrow  tag,  vx,  vi,  direction, fintxgrid,  first igrid, 
lastxgrid,  lastxgrid) 

Object  navbox; 

Tag  arrowtag; 

Coord  vx,  vs; 
double  direction; 

short  firstxgrid,  firstcgrid,  lastxgrid,  lastsgrid; 

{ 

Coord  arrow x,  arrowy,  larrowx,  1  arrowy,  r arrow x,  rarrowy; 

/*  compute  coordinates  of  arrow  line  segments  for  nav  control  box  */ 

arrow x  =  vx  +  cos(direction)  *  2.0  *  FEETPERGRID; 

arrowy  =  vs  -  sin(direction)  *  2.0  *  FEETPERGRID; 

larrowx  =  arrowx  +  cos(direction  -  2.3561945)  *  FEETPERGRID; 

1  arrowy  =  arrowy  -  sin(direction  -  2.3561945)  *  FEETPERGRID; 
r arrowx  =  arrowx  +  cos(direction  +  2.3561954)  *  FEETPERGRID; 
rarrowy  =  arrowy  -  sin(direction  +  2.3561945)  *  FEETPERGRID; 

/*  update  the  contour  map  display  with  new  info  */ 

editobj(navbox); 

objreplace(arrowtag); 

move2(vx,vs); 

draw2( arrowx,  arrowy); 

draw2(larrowx,  larrowy); 

move2( arrowx,  arrowy); 

draw2(raiTowx,  rarrowy); 

rec  t  ( firstxgrid  *  FT  1 00M ,-  first  sgrid  *  FT _1 00 M, 

( lastxgrid + 1 )  *  FT  100M ,  (-lastsgrid- 1 )  *  FT  100M ) ; 
closeobj(); 

} 
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EXPLOSION 


^include  "gl.h" 
explosion  (} 

{ 

int  i  j; 

pushviewport(); 
viewport  (0, 102$  ,0,787 ) ; 
color(BLACK); 

cl«nr(); 

swapbuffers{); 

color(RED); 

clear(); 

swapbuffera(); 

swapbuffers(); 

color(  YELLOW); 

clear  (); 

swapbuffera(); 

swapbuffers(); 

color(RED); 

clear(); 

swapbuffere(); 
swapbuffers(); 
color(  YELLOW), 
clear(); 
swapbuffera(); 
swapbuffen(); 
color  (RED); 
dear(); 
swapbuffera(); 
swapbuffera(); 
for  (i  =  0;  i  <  100000;  i++) 
for  (j  =  0;  j  <  10;  j++); 
popviewport(); 

} 


1ST 


POGM  (MAIN) 


/*  fogm.c  —  an  IRIS-2400  program  by  Doug  Smith  k  Dale  Streyle 
It  reads  in  a  10km  x  10km  section  of  a  terrain  map,  computes  a  lighting 
and  shading  model  for  the  terrain,  and  allows  overflight  */ 

#include  "gl.h"  /*  get  the  graphics  defs  */ 

#include  "device. h"  /*  get  the  graphics  device  defs  */ 

finclude  "fogm.h"  /*  constants  */ 

finclude  "math.h"  /*  math  function  declarations  */ 

#include  "get.h"  /*  monitor  type  include  file  */ 

finclude  "stdio.h" 

finclude  "sys/signal.h"  /*  used  for  screen  dump  utility  */ 
finclude  <sys/types.h>  /*  contains  the  time  sturcture  tms  */ 
finclude  <sys/times.h>  /*  for  time  calls  •  */ 

short  gridpLxel[  100] [  100];  /*  DMA  elevation  and  vegatation  data  */ 
float  savetriangle(99](99][2]|S]j3]; 
long  gridcolor(99][99j; 

Object  road|99][99|; 

Object  target[99|[99); 

float  ground_plane|4][S|; 

long  gnd  plane  color; 

float  tgt  pos[MAX_TGTS]|S|; 

short  tgt  grid  idx|MAX  TGTSj[2j; 

short  tgt  dirjMAX  TGTS],  tgt  total  =  0; 

float  randx,  randy,  rands;  /*  random  offsets  from  tank  reference  point  */ 

int  framecnt; 

float  min  elev,  max_elev; 

Coord  tankx,  tanky,  tanks; 
float  frames_sec[1000j[2|; 


mainQ 

{ 

int  greyscale  =  FALSE;  /*  FALSE  =  color,  TRUE  =  greys  *  j 


int  designate;  /*  boolean  indicating  desig/reject  status  * / 

int  flying  =  TRUE;  /*  boolean  controlling  flying  loop  */ 

int  active  =  TRUE;  /*  boolean  controlling  main  program  loop  */ 
int  nbyte,  socket,  connect  client();  /*  networking  variables  k  subroutine  */ 
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struct  tms  timestruct;  /*  structure  for  real-time  clock  calls  */ 

int  tgtidx;  /*  index  of  designated  target  */ 

double  direction;  /*  direction  of  travel  in  radians  */ 

float  speed;  /*  speed  of  travel  in  knots  */ 


float  compassdir;  /*  desired  direction  of  travel  in  compass  deg  */ 

int  fovy  =  550;  /*  field  of  view  in  perspective  command  */ 

double  pan  =  0.0, 

tilt  =  -15.0  *  DTOR;  /*  pan  and  tilt  angles  */ 

/*  contour  map,  indicator,  instruction  .*/ 

Object  contour,  navbox,  indbox,  instrbox; 

Object  tank,  pre_l_obj|7]; 

Tag  headingtag,  elevtag,  speedtag,  soomtag,  arrowtag,  tilttag,  pantag; 
Tag  desigtag,  altmsltag,  pre_l_tag|0|; 

Colorindex  unmask; 

Coord  vx,  vy,  vs;  /*  viewer  x  y  and  t  coordinates  */ 

Coord  px,  py,  pt;  /*  reference  x  y  *  coordinates  for  lookat  */ 

Coord  tgtx,  tgty,  tgts;  /*  targeted  position  on  tank  */ 
float  randseed();  /*  random  number  generator  initialisation  */ 
int  frames  =  -1; 

long  seconds,  lastseconds,  totalseconds  =  0; 
int  numpolys; 
float  elapsed; 
int  idx; 

FILE  *fopen(),  *fp; 

/*  first  and  last  x  and  s  indexes  of  the  grid  objects  to  draw  */ 
short  firstxgrid,  firstsgrid,  lastxgrid,  lastsgrid; 

readdata();  /*  read  the  data  file  into  the  gridpixel  array  */ 

/*  get  socket  number  for  networking  */ 

/•if  (NETWORKING)  socket  =  connect_client("npscs-irisI",S);  */ 

init_iris();  /*  initialise  the  iris  */ 

unmask  =  (l<<getplanes())  -  1; 
writemask(unmask); 


randseed(times(&timestruct));  /*  seed  the  random  #  generator  */ 


init_tgts();  /*  define  target*  */ 

Screen  Dump(SCREENDUMP);  /*  enable  screen  dumping  */ 

billboard();  /*  produce  intro  screen  */ 

colorramp(grey scale,' TRUE);  /*  build  all  color  ramp*  */ 

makescreens(pre_l_obj,  preltag);  /*  build  objects  for  prelaunch  */ 
makemap(&contour);  /*  build  map  object  */ 

pre  l  obj  [CONTOUR]  =  contour; 

prelaunch (tvx,  lev y,  levs,  Indirection,  lecompassdir, 

Inactive,  pre  l  obj,  pre  l  tag); 

if  (active)  { 

maketank(letank);  /*  build  object  for  a  tank  */ 

build  road() ;  /*  build  the  objects  that  comprise  the  roads  */ 

/*  process  terrain  data  to  build  polygons  and  compute  lighting  */ 
buildterrainQ; 

/*  build  object  for  the  navigation  display  contour  map  */ 
draw  nav  box  (fcnav  box,  &  arrow  tag); 

/*  build  an  object  for  the  indicator  box  */ 

makeindboxf&indbox.&headingtag.&eievtag.&altmsltag.&speedtag, 

lezoomtag.letilttag.&pantag.&desigtag); 

•iiakeinstrbox(leinstrbox);  /*  build  object  for  control  instruction  box  */ 


}  /*  end  of  if  (active)  block  */ 

while  (active)  { 

frameent  =  0; 

/*  initialise  the  operator  controls  (mouse  and  dials)  */ 
init  controls(lepan,  letilt,  lefovy,  vy,  greyscale,  compassdir); 

pushviewportQ; 
viewport(0, 1023,0,787); 
color(SKYBLUE); 
clear(); 

f>opviewport(); 
callobj(instrbox); 
callobj(indbox); 
editobj(contour); 
objreplace(ST  ARTT  AG); 
viewport(78«, 1023, 512, 787); 


closeobj(); 
callobj(contour) ; 
swapbuffers(); 
callobj(instrbox) ; 
callobj  (contour); 
editobj  (contour); 
objreplace  (ST  ARTT  AG ) ; 
view  port(0, 768, 0,768); 
closeobjQ; 

flying  =  TRUE;  /*  missile  is  flying  */ 
designate  =  TRUE;  /*  a  target  can  be  designated  */ 

while(flying)  {  j*  until  tgt  is  bit  or  5-button  exit  */ 


/*  get  values  from  user  contols  (mouse  and  dials)  */ 
read_controls(itdesignate,  t  grey  sc  ale,  Jtflying,  Inactive, 
id  speed,  t  direct  ion,  iccompassdir,  levy, 
id  pan,  ittilt,  iefovy); 

/*  calculate  which  target  was  closest  to  the  line  of 
sight  */ 
if  (^designate)  { 

nearest  tgt(vx,vy, vs, px,py,ps,ittgt  idx); 

} 

/*  update  targets'  positions  •/ 

get _tg t _posi t (soc ket ,  designate,  tgtidx,  ictgtx,  it  tgty,  It  tgts,  tank); 
/*  update  missile  position  */ 

update_misaile_posit(icdirection,  Itcompassdir,  speed, 
designate,  tgtx,  tgty,  tgts, 
itvx,  levy,  tvs,  ieflying); 

/*  update  camera  lookat  position  */ 
update_look_posit(direction,  pan,  tilt,  vx,  vy,  vs, 
tgtx,  tgty,  tgts,  designate,  it px,  Itpy,  itps); 

/*  determine  which  polygons  need  to  be  drawn  */ 
view  bounds(vx,  vy,  vs,  px,  py,  ps,  tilt,  fovy, 

Itfirstxgrid,  A  firsts  grid,  itlastxgrid,  itlastsgrid); 

/*  edit  control  display  objects  to  reflect  new  values  */ 
edit_navbox(navbox,  arrowtag,  vx,  vs,  direction,  firstxgrid, 
firsts  grid,  lastxgrid,  lastsgrid); 

edit_indbox(indbox,  speedtag,  heading  tag,  e  lev  tag,  ahmsltag , 
soomtag,  tilttag,  pantag,  desigtag,  speed, 
compassdir,  vx,  vy,  vs,  pan,  tilt,  fovy,  designate); 


/*  display  the  3-D  view  of  the  terrain  as  seen  by 


the  camera  */ 

display_terrain(vx,  vy,  vi,  px,  py,  pi,  fovy, 
firatxgrid,  firstsgrid,  lastxgrid,  lastsgrid); 

/*  display  the  control  boxes  */ 

writemask(SAVEMAP); 

eallobj(navbox); 

writemask(unmask); 

callobj(indbox); 

swapbuffers(); 

seconds  =  times(Jdtimestruct); 

numpolys  —  (lastxgrid  -  firstxgrid)*(lastsgrid-firstsgrid)*2; 
elapsed  -  (float) (seconds  -  lastseconds)/60.0; 
if  ((frames  >=  0)  tiL  (frames  <  1000)  ){ 

frames  sec[frames](0)  =  (float)numpolys; 
frames  sec|frames|(l |  =  1.0/elapsed; 

} 

totalseconds  +=  (seconds-lastseconds); 
if  (totalseconds  >  7200)  { 

compactifyQ;  /*  do  garbage  collection  every  2  mins  */ 
totalseconds  =  0.0; 

} 

lastseconds  =  seconds; 
frames  +=  1; 

}  j*  end  of  flying  loop  */ 

if  (active)  {  /*  explode  ti  restart  */ 

explosionQ; 

prelaunch(&vx,  &v y,  dcvi,  ^direction,  &cotnpassdir, 

^active,  pre  j  obj,  pre  l  tag); 

} 

}  /*  end  of  active  loop  */ 

/*  write  out  performance  stats  */ 
fp  =  fopen("speed.data",  "w"); 
if  (frames  >  999)  frames  =  999; 
for  (idx  =  0;  idx  <=  frames;  +  +  idx)  { 

fprintf(fp,"%.2f  %.2f0,  fraines_sec|idx)|0),  frames _sec[idx)|lj); 


} 
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/*  gracefully  exit  */ 

if  (NETWORKING)  cloae(aocket); 

•etmonitor(HZOO) ; 

color(BLACK); 

c»e*r(); 

swapbufTers(); 

cl*ar(); 

gexit(); 

textinit(); 

exit(); 

}  /*  end  of  main  */ 


FILES. H 


/*  These  are  the  files  which  contain  data  for  the  terrain  elevations 
and  roads  */ 

# define  TERRAIN_FILE  "/work/terrain/tenkmsq.dat" 

#define  ROAD  FILE  "/work/terrain /Road. data" 

FOGM.H 

fdefine  elev  mask  OxlffT  /*  mask  to  obtain  elev  value  from  datum  */ 

fdefine  vegjnwk  0x0007  /*  mask  to  obtain  vegatation  value  from 


shifted  datum  */ 

#define  RD  0  /*  code  for  reading  a  file  in  "open"  */ 

#define  MAX  2800  /*  max  elev  (ft)  in  contour  map  */ 

#define  MIN  967  /*  min  elev  (ft)  in  contour  map  */ 

#define  SKYBLUE  4095  /*  color  index  for  sky  color  */ 

#define  ROADGREY  850  /*  color  index  for  the  road  */ 


#define  DELTAFOVY  50  /*  field  of  view  (loom)  increment  of  5  deg  */ 

#define  PI  3.1415927 

IdefineTWOPI  6.2831853 

#define  HALFPI  1.5707963 

#define  THREE  HALVES  PI  4  7123889 

#define  QTR  PI  0  7853982 

#define  THREE  QTR  PI  2  3561945 

fdefine  FIVE  QTR  PI  3.9269908 

#define  SEVEN  QTR  PI  5.4977871 

#define  RTOD  57.29578  /*  radians  to  degrees  conversion  factor  */ 

#de6ne  DTOR  0.0174533  /*  degrees  to  radians  conversion  factor  */ 

#define  FPS  TO  KTS  35.525148  /*  convert  feet  per  60th  seconds  to  knots  •/ 


# define  PANSENS  SO.O  /*  scale  factors  (sensitivity)  for 

navigaion  controls  (mouse  and  dials)  */ 

#define  SPEEDSENS  20 

#define  TILTSENS  50.0 

#define  DIRSENS  20.0 

#define  MAXLOOKDIST  32808.0  /*  maximum  distance  that  the  camera  can 
look  ahead  in  feet  */ 

fdefine  FEETPERGRID  3280.8  /*  number  of  feet  in  1000  meters  */ 


#de6ne  ALTSCALE  1.05  /*  altitude  expansion  factor,  altitudes  are 

raised  to  this  power  to  give  an 
exagerrated  effect  */ 


fdefine  NUMXGRIDS 

10 

/*  number  of  lK  grid  squares  in  the  East- 

West  direction  */ 

fdefine  NUMZGRIDS 

10 

/*  number  of  lk  grid  squares  in  the  North- 

South  direction  */ 

#define  FT  10K 

32808 

/*  number  FT  in  lOKm  */ 

#define  FT  100M 

328.08 

/*  number  FT  in  100m  */ 

#define  GRID  FACTOR 

13.03781  /*  conversion  factor 

fdefine  TV  0 

r 

0  for  SGI  monitor,  1  for  TV  */ 

#define  SCREENDUMP  1 

/*  1  to  enable  screen  dumping,  0  otherwise 

#define  NETWORKING  0 

/*  1  for  target  networking,  0  otherwise  * 

#define  INIT  PAN 

0 

/*  initial,  min  and  max  pan  angles  in  deg.  */ 

#de6ne  MIN  PAN 

-25 

^define  MAX  PAN 

25 

Idefine  INIT  TILT 

-15 

/*  initial,  min  and  max  tilt  angles  in  deg.*/ 

fdefine  MIN  TILT 

-25 

fdefine  MAX  TILT 

15 

#define  MAX  ALT 

17000 

/*  maximum  altitude  for  missle  */ 

# define  MIN  ALT 

0 

/*  minimum  altitude  for  missle  */ 

#define  INIT  SPEED 

200 

/*  init,  min  and  max  spd  (kts)  for  missle  */ 

#define  MIN  SPEED 

0 

#define  MAX  SPEED 

400 

#de6ne  INIT  FOVY 

550 

/*  initial  held  of  view  in  tenth  degrees  */ 

106 


#define 

CONTOUR 

0  /*  Indictee  for  trr&y  obj 

#define 

SCREEN1 

1 

^define 

SCREEN2 

2 

#define 

SCREENS 

3 

^define 

INSTR 

4 

# define 

STATS 

5 

# define 

FLTPATH 

6 

#define 

LAUNCH 

0 

/*  Indictee  for  urty  teg 

#define 

TARGET 

1 

#define 

DIR 

2 

#define 

HEAD 

3 

#define 
# define 

TGT  4 

MISSILE 

5 

#define  MAX  TGT  COLOR  847 
# define  MIN  TGT  COLOR  668 


#define  MAX  TGTS  100 


idefine  SAVEMAP 


OxOOCO 


GAMMARAMP 


/*  This  routine  puts  a  gamma-corrected  color  ramp  into  the  color  map.  */ 
#  include  <math.h> 

gammaramp(gammaconst,firstcolor,ncolors, 
brightred,brightgreen,brightblue, 
darkred, darkgreen, darkblue) 

float  gammaconst;  /*  Strength  of  Gamma  correction  (try  1.0)  */ 
long  firstcolor;  /*  index  number  of  the  first  color  to  set  */ 
long  ncolors;  /*  the  number  of  colors  to  set  */ 
long  brightred,brightgreen,brightblue;  /*  the  bright  end  of  the  ramp  */ 
long  darkred.darkgreen.darkblue;  /*  the  dark  end  of  the  ramp  */ 

{ 

long  i;  /*  temp  loop  index  */ 

float  scl;  /*  scale  factor  for  gamma  correction  */ 

long  gcred.gcgreen.gcblue;  /*  gamma  corrected  colors  */ 

for(i=0;  i  <  ncolors;  i++)  /*  for  all  colors...*/ 

{ 

/*  compute  the  scale  factor  */ 

scl  =  pow((float)i/(float)(ncolors-l)  ,  1.0/gammaconst); 

/*  compute  the  gamma  corrected  colors  */ 
gcred  =  scl  *  (brightred  -  dark  red)  +  darkred; 
gcgreen  =  scl  *  (brightgreen  -  darkgreen)  ■+  darkgreen; 
gcblue  =  scl  *  (brightblue  -  darkblue)  -+  darkblue; 

mapcolor(firstcolor+i,  gcred,  gcgreen,  gcblue);  /*  set  the  color  */ 

} 

} 
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/*  get  targets’  positions  from  irisl  if  networking.  Otherwise  move*  10  target* 
in  straight  lines,  reversing  when  they  hit  an  edge  */ 


f  include  "fogm.h" 

#  include  "gl.h" 

# include  "math.h" 

#  include  <sys/types.h>  /*  contains  the  time  sturcture  tms  */ 
# include  <sys/times.h>  /*  for  time  calls  */ 


get  tgt  posit(socket,designate,tgt_idx,tgtx,tgty,tgti, tank) 


int  socket,  designate,  tgtidx, 
float  *tgtx,  *tgty,  *tgts; 
Object  tank; 


{ 


extern  float  tgt_pos[MAX_TGTSj(S|; 

extern  float  randx,  randy,  rands; 

extern  Object  target[99  [99]; 

extern  short  tgt  grid  idx(MAX_TGTS||2j; 

extern  short  tgt  total,  tgt_dir|MAX  TGTS); 

short  i,  tgt  sum; 

int  nbyte,  addlQ; 

float  gnd  level(),  dir,  dx,  ds,  distance; 
long  dist,  d2, 
static  long  seconds; 

static  long  lastsec  =  -999;  /*  -999  is  flag  to  indicate  no  value  */ 

struct  tms  timestruct; 


seconds  =  times(&timestruct); 


if  (lastsec  ==  -999)  /*  compute  distance  targets  move  ahead  */ 
distance  =  0.0; 

else 

distance  =  (float)((15.0/FPS_TO_KTS)*(seconds  -  lastsec)); 


lastsec  =  seconds; 


/*  save  for  next  pass  */ 


for  (i  =  0;  i  <  tgt  total;  i+  +  )  /*  delete  targets  from  old  positions  */ 

if  (targetjtgtgrid _idx|i||0]]|tgt_grid_idx|i||l]))  { 

delobj(target[tgt_grid_idx(i|(0||[tgt_grid_idx(i|(l|j); 
target  |  tgt  grid  _idx|i]|0]|jtgt_grid  _idx[i][l|]  =  0; 

} 


if  (NETWORKING)  { 

nbyte  =  read(socket,  &tgt_total,  siseof(tgt_total)); 
for  (i  =  0;  i  <  tgt  total;  i+  +  )  { 

nbyte  =  read(socket,  ittgtgrid  jdx[i][0),  siseof(short)); 
nbyte  =  read(socket,  &tgt_grid_idx[i|[l),  siseof(short)); 
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nbyte  =  re  ad  (socket,  &tgt_po*[i][0|,  t  is  eof  (float)) 
nbyte  —  read  (socket,  fl^fcgt_po*(i}|l),  siseof(flost)) 
nbyte  =  read  (socket,  &tgt_poe[i|[2),  siseof(float)) 
nbyte  =  read(socket,  itgt  dirji],  siseof (short)); 


tgt  total  =  10; 

for  (i  =  0;  i  <  tgttotal;  i++)  ( 

dir  =  (float)(tgt_dir(iJ  /  10)  *  DTOR; 
tgt _P°e|i!(0]  +=  cos(dir)  *  distance; 
tgt_pos[i][2)  -=  sin(dir)  *  distance; 
tgt_grid_idx(i)|0]  =  (short)(tgt_pos|i)[0|/FT_100M); 
tgt_grid_idx|ij|l)  =  (short)j-tgt  pos[i](2|/FT  100M); 
if  ((tgt_pos|i)[0)  >  FT  10K)  |j  (tgt_pos|i)|0)  <  0))  { 
if  (tgt  _dir[i|  >  1800)  tgt_dir|i)  -=  1800; 
else  tgt_dirji]  +=  1800; 
tgt  _pos(i|[l|  =  0.0; 

> 

else  if  ((tgt  pos|ij|2)  <  -FT10K)  ||  (tgt_pos[i]|2]  >  0))  { 
if  (tgt  dir[i]  >  1800)  tgt_dirji)  -=  1800; 
else  tgtdirji)  +=  1800; 
tgt_posji]|l]  =  0.0; 

} 

else  tgt_pos[i][l)  =  gnd_level(tgt_pos|i]|0],  tgt_pos[i)[2|); 


if  ^designate)  { 

if  (NETWORKING)  (  /*  find  which  target  is  designated  * / 

dist  =  up _i(( float )( tgt _pos[0]|0j  -  *tgtx),2)  + 
up  j((float)(tgt  pos(0|[2]  -  * tgts ) ,2) ; 
tgtidx  =  0; 

for  (i  =  1;  i  <  tgt  total;  i++)  { 

d2  =  u p_i( (float) (tgt_pos(i][0]  -  *tgtx),2)  + 
up _i((float)(tgt_pos[i|(2l  -  *tgts),2); 
if  (d2  <  dist)  { 
dist  =  d2; 
tgt_idx  =  (int)i; 

} 


*tgtx  =  tgt_pos|tgt_idxj|0]  +  randx; 

*tgty  =  tgt  _pos|tgt _ idx]  j  1  j  +  randy; 

*tgts  =  tgt_pos(tgt_idx|(2j  +  rands; 

} 

tgt_num  =  tgt_total; 

for  (i  =  0;  i  <  tgt  num;  i+  +  )  { 

dx  =  tgt  pos|i](0]  -  (float)tgt_grid_idx|i]|0|  *  FT  I00M; 
ds  =  (float)(-tgt_grid_idxjij|l])  *  FT100M  -  tgt_posji||2); 
if  (dx  <  15.0) 

if  (ds  <  15.0)  { 
add  1  (i,- 1 ,0) ; 


ITfSC' 


addl(i,-l,-l); 

addl(i,0,-l); 


else  if  (di  >  315.0)  { 

addl(i,0,l)i 

addl(i,-l,l); 

*ddl(i,-l,0); 

} 

else  addl(i,-l,0); 

else  if  (d*  >  313.0) 
if  (ds  <  15.0)  { 

addl(i,0,-l); 

sddi(i.i.-i); 

addl(i,l,0); 

} 

else  if  (ds  >  313.0)  { 

&dd  1  (i,  1 ,0) ; 
addl(i,l,l); 

add  1  (i,0, 1 ) ; 

} 

else  &ddl(i,l|0); 

else  if  (ds  <  15.0)  &ddl(i,0,-l); 

else  if  (ds  >  313.0)  addl(i,0,l); 


for  (i  =  0;  i  <  tgt  total;  i++)  /*  add  targets  to  new  positions  */ 

if  (target | tgt  grid  _idx|ij [0] |(tgt_grid _idx(i)(  1)| )  { 

editobj(target{tgt  grid _idx(i|[0]]|tgt_grid_idx[i][l|)); 
pushmatrix(); 

tranalate(lgt_pos(i|[0],tgt_pos[i|jl|,tgt_pos|i]|2]); 

rotate(tgt_dir(i],  ’Y’); 

callobj(tank); 

popmatrix(); 

closeobj(); 


target  |  tgt  _grid_idx|i)(0j)  [tgt  _grid_idx[i)[l]]  =  genobj(); 
makeobjj  target  [tgt  _grid_idx[i)jO]]|tgt_grid_idx[i]|l]|); 
pushmatrix(); 

translate(tgt_posji|[r,|,tgt  pos[i)[lj,tgt_pos[i][2]); 

rotate(tgt_dir(i|,  ’Y’); 

callobj(tank); 

popmatrixQ; 

closeobj(); 


add  1  (tgt  num.x.z) 


short  tgt_num,x,s; 

{ 

extern  float  tgt_pos|MAX_TGTSj|3]; 
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extern  ihort  tgt_grid_idx(MAX_TGTS)(2); 
extern  ihort  tgttotal,  tgt_dir[MAX_TGTS); 
short  i; 


tgt_pos|tgt_totalj[0]  =  tgt_pos(tgt_num]|0];  /*  copy  pot.  for  "new"  tgt  * / 
tgt_posjtgt_totaljjl]  =  tgtposjtgtnumjjlj; 
tgt_poa[tgt_totalj|2]  =  tgt_pos|tgt_numj{2]; 

tgt_dir[tgt_total]  =  tgt_dir[tgt_numj;  /*  copy  dir  for  "new"  tgt  */ 
tgt  grid  idxjtgt  total) [0]  =  tgt_grid_idx[tgt_num]|0)  +  x;  /*  set  pot  in  */ 
tgt_gr*d_idxjtgt_total][l)  =  tgt_grid_idxjtgt_num)il)  +  ■;  /*  new  grid  sq  */ 
for  (i  =  0;  i  <  2;  i+  +  )  {  (*  reset  if  new  grid  sq  outside  10km  square  */ 

if  (tgt_grid_idx|tgt_totalj(i)  <  0)  tgt_grid_idx[tgt_total)|i]  =  0; 
if  (tgt_grid_idx(tgt_total][ij  >  98)  tgt  grid _idx[tgt _totalj|i]  =  98; 

} 

tgt  total  ++; 


GND  LEVEL 


♦  include  "mnth.h" 

♦  include  "fogmh" 

♦define  X  0 
^define  Y  1 
♦define  Z  2 

float  gnd  level(vx,  vs) 

float  vx,  vi; 

{ 

extern  short  gridpixel)  100]  1 100] ; 
float  interp  _elev(); 
float  grid  _level(); 

float  point|S],  nw_corner(Sj,  ne_corner|S|,  sw  cornerjS),  se  corner|S); 
float  interaect(Sj; 
float  elev; 

int  xgrid,  (grid,  inters ect  type; 

/*  determine  which  triangle  the  point  fails  in  */ 

xgrid  =  (int)(vx/FT  100M); 

sgrid  =  (int)(-vs/FT  100M); 

if  (xgrid  <  0)  xgrid  =  0; 

if  (xgrid  >  98)  xgrid  =  98; 

if  (sgrid  <  0)  sgrid  =  0; 

if  (sgrid  >  98)  sgrid  =  98; 

point(X|  =  vx; 

pointjZI  =  -vs; 

nw  corner[X]  =  (float)(xgrid*FT  100M); 
nw_corner|Z|  =  (float)((sgrid  +  1)*FT_100M); 
elev  =  gridpixel(sgrid+l|(xgrid|  4c  elevmask; 
nw_corner|Y]  =  pow(elev,  ALTSCALE); 
sw  corner|X|  =  (float)(xgrid*FT  100M); 
sw  corner (Z |  =  (float) (sgrid* FT  100M); 
elev  -  gridpixel|sgridj|xgrid]  Sc  elev  mask; 
sw  corner(Y|  =  pow(elev,  ALTSCALE); 
ne  corner(X|  =  (float)((xgrid  +  l)*FT  100M); 
ne  corner|Z|  =  (float)((sgrid+l)*FT_100M); 
elev  =  gridpixel(*grid-t-l]|xgrid+l]  Sc  elev  mask; 
ne  corner|Y|  -  pow(elev,  ALTSCALE); 
se  comer[X|  =  (float )((xgrid  +  1)*FT  100M); 
se  cornerj Z]  =  (floet)(sgrid*FT  100M); 
elev  =  gridpixel(sgridj(xgrid  +  lj  Sc  elev  mask; 
se  corner) Y]  =  pow(elev,  ALTSCALE); 

if  (-vs  <  (nw_eorner(Zj  -  (vx  -  nwcorner(X))))  { 

/*  point  is  in  the  lower  triangle  */ 


/*  find  the  point  of  intersection  of  a  line  through  vx,vs 
and  the  sw  corner  with  the  diagonal  */ 
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line  intersect2(sw _corner,  point,  nw_corner,  secorner,  intersect, 
^intersect  type) ; 

/*  find  the  elevation  of  the  intersection  on  the  diagonal  */ 
intersect|Yj  =  interp_elev(nw_corner,  se_corner,  intersect); 

/*  find  the  elevation  of  the  point  vx,  vy  */ 
return(interp_elev(»w_corner,  intersect,  point)); 
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/*  point  is  in  the  upper  triangle  */ 

/*  find  the  point  of  intersection  of  the  diagonal  with  a  line 
through  th  ne  corner  and  the  point  */ 
line_intersect2(ne_corner,  point,  nw_corner,  se_corner,  intersect, 
^intersect  type); 


m 
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/*  find  the  elevation  of  the  intersection  on  the  diagonal  */ 
intersectjY]  =  interp_elev(nw  corner,  secorner,  intersect); 

/*  find  the  elevation  of  the  point  vx,  vs  */ 
return(interp_elev(ne  corner,  intersect,  point)); 


IN  THIS  POLY 


^include  "gl.h" 

((define  X  0 

((define  Y  1 

((define  Z  2 

((define  PROPER  2 


int  in  this  poly  (polygon,  num_vertex,  point) 
float  polygon|10|[3|; 
int  num  vertex; 
float  point[S|; 

{ 

int  index; 

int  pt  in,  intersecttype; 

int  numcrossings; 

float  mix  x,  max  s,  min  x,  min  s; 

float  intersect[3|; 

float  old  intersect[3|; 

float  start  test  line[3); 

max  x  =  polygonjOjjX); 
min  x  =  polygon[0||X|, 
maxi  =  polygon|0|[Z]; 
min  i  =  polygon[0][Z|; 


for  (index  =  1;  index  <  numvertex;  ++index)  { 

if  (polygon|index]|X|  <  min  x)  min  x  =  poly gon| index] |X); 
if  (polygon[index)|X)  >  mu  x)  maxx  =  polygon[indexj|X); 
if  (polygon|index)|Z]  <  min  i)  min  i  =  poIygonjindexj(Z); 
if  (polygon|index]{Z|  >  max  i)  max  i  =  polygon|index||Zj; 

} 

if  ((point[X|  <  mu  x)  ScSc  (pointjX)  >  min  x)  (point[Z)  <  max  i)  iiL 
(point | Z1  >  min  i))  ( 


/*  point  may  be  polygon,  lest  further  by  constructing  a  vertical  line 

from  the  point  to  a  point  outside  the  polygons  bounds.  Count  the  number 
of  times  this  line  crosses  a  side  of  the  polygon.  If  it  crosses  an 
odd  number  of  times  the  point  is  in  the  polygon,  otherwise  it  is 
outside  the  polygon  */ 


start  test Jir.e|X)  =  pointjX]; 
start  test  linejZ]  =  max_i  +  1000.0; 


num  crossings  =  0; 
old  intersect |XJ  =  -999.0; 
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oldinlersectjZ]  =  -999.0; 

for  (index  =  0;  index  <  numvertex  -I;  +  + index)  { 

linejntersect2(start_test_line,  point,  &  polygon  (index  ]|0|, 
<dpolygon(index+ 1||0],  intersect,  ^intersect  type); 

/*  if  n  proper  intersection  exist*  end  it  is  not  the  same  point 

as  the  previous  intersection  (i.e  it  didn’t  intersect  a  vertex), 
then  add  one  to  the  number  of  crossings  */ 
if  ((intersecttype  ==  PROPER)  kk  ((intersect|X)  !=  old  intersect(X)) 
||  (inter*ect|Z|  !=  old_intersect[Z|)))  numcrossings  +=  1; 
oidintersectjXj  =  intersect|Xj; 
old  intersect jZ]  =  intersect(Z|; 

} 

iine_intersect2(start_test  line,  point,  &polygon|num_vertex-l)|Oj, 
&fx>)ygon(0](0],  intersect,  ^intersect  type); 
if  (intersect  type  ==  PROPER)  num  crossings  -t-=  1; 

j*  if  the  number  of  crossings  is  even,  the  point  was  outside  */ 
pt  in  =  ((num  crossings  %  2)  !=  0); 
return (pt  in); 

> 

else  ( 


return(FALSE); 


INIT  CTELS 


/*  initialise  the  operator  controls  */ 


#  include  "fogm.h" 
^include  "device. h" 
#include  "gl.h" 
#include  "math.h" 


/*  fogm  constants  */ 

/*  graphics  device  definitions  */ 
/*  graphics  routine  definitions  */ 
/*  math  function  definitions  */ 


init  controls(pan,  tilt,  fovy,  alt,  greyscale,  compassdir) 


double  *pan; 
double  *tilt; 
int  *fovy ; 

Coord  alt; 
int  greyscale; 
float  compassdir; 


/*  initial  pan  angle  in  radians  */ 

/*  initial  tilt  angle  in  radians  */ 

/*  initial  field  of  view  in  tenths  of  degrees  */ 
/*  initial  altitude  of  missile  */ 

/*  initial  value  of  greyscale  boolean  */ 

/*  initial  compass  direction  */ 


{ 


‘pan  =  INIT  PAN  *  DTOR; 
‘tilt  =  INIT  TILT  *  DTOR; 
‘fovy  INIT  FOVY; 


/*  set  initial,  min,  and  max  values  for  mouse  Sc  dials  */ 

set valuator(MOUSEX, (short) (INIT  PAN*PANSENS),(short)(MlN  PAN*PANSENS), 
(short) ( MAX  PAN*PANSENS)); 

setvaluator(MOUSEY, (short) (INIT  TILT*T>LTSENS),(short)(MIN  TILT*TILTSENS), 
(short) ( MAX  TILT*TILTSENS));  " 


set  valuator)  DIALO,  (short)  (compassdir*DIRSENS),  (short)  (-360*DIRSENS), 
(short)  ( 720*  DIRSENS)), 


set valuator( D1 A L4,  (short)  alt,  MIN  ALT,MAX_ALT); 

set  valuator)  D1AL2,  (short)(INIT_SPEED*SPEEDSENS), 
(short)(MIN  SPEED'SPEEDSENS), 

(short)(MAX  SPEED'SPEEDSENS)); 

setvaluator(DIAL3, greyscale, 0,1), 

} 


INIT  nus 


/*  Initialise  the  graphics  environment  for  the  iris  workstation  */ 


^include  "gl.h" 
^include  "get.h" 
#include  "fogm.h" 

init_iris() 

{ 

long  chunk; 


/*  graphics  definitions  */ 

/*  monitor  type  definitions  */ 
/*  fogm  constants  */ 


ginitQ; 

doublebufferQ; 
chunk  =  128; 
chunksise(chunk); 
gconfig(); 
if  (TV)  { 

setmonitor(NTSC); 
fontdef(l  ,"TV  .font") ; 
font(l); 

} 

else  setmonitor(HZ60); 

cursoff();  /*  turn  off  the  cursor 


/*  number  of  bytes  be  which  objects 
increment  */ 

/*  initialise  the  IRIS  system  */ 

/*  put  the  IRIS  into  double  buffer  mode  */ 


/*  (means  use  the  above  command  settings)  */ 
/*  choose  tv  or  SGI  monitor 
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backface(TRUE); 


/*  turn  on  backface  polygon  removal 


color(BLACK); 

clear(); 

swapbuffers(); 


INIT  TGTS 


#include  "fogm.h" 

#include  "gl.h" 

init_tgta() 

{ 

extern  short  tgt_total; 
extern  Object  target[99]  99|; 
short  x,  y; 
int  inittgtj); 

for  (x  =  0;  x  <  99;  x++)  for  (y  =  0;  y  <  99;  y+  +  )  tvget|xj[y| 
if  (INETWORKING)  { 

tgt  total  =  10; 
imt_tgl(0, 9  8,3.5,1295); 
init  tgtj  1,9  5,3  5,1295); 
init  tgt(2, 9.4, 3  1,1295); 
init  tgt(3,9.8, 0.5, 1800); 
init  tgt (4, 9. 5,0  0,1355); 
init  tgt (5, 8. 0,0. 0,1445); 
init  tgt(6, 4.0, 00, 1450); 
init  tgt(7, 0.0,0  5,450); 
init  Jgt(8, 9.5, 9  8,2700); 
init  tgt(9,9  8,8  5,1800); 

} 

} 

init  tgt { tgt  num.xoffset.soffset, direction) 

short  tgt  num,  direction; 
float  xoffset,  soffset; 

{ 

extern  short  tgt  dirjMAX  TGTS); 
extern  float  tgt  posjMAX  TGTSj[3|; 

tgt  pos  tgt  numj|0j  =  xoffset  *  FEETPERGRID, 
tgt  pos  tgt  numl[2]  =  -soffset  *  FEETPERGRID; 
tgt  dirltgt  num|  =  direction; 


) 


INTERP  ELEV 


#inelude  "math.h” 

#define  X  0 

#define  Y  1 

fdefine  Z  2 

float  interp  elev(line_start,  lineend,  point) 

float  line_start|3),  lineend(S),  point|3]; 

{ 

long  float  linejieltax,  line  deltas,  point_deltax,  point_deltai; 
float  linejength,  dist_to_point; 
float  interpolation; 

line  deltax  =  (long  float)(line_endjX]  -  line  atartjXj); 
line  deltas  =  (long  float) (line  end[Z]  -  line_start[Z]); 

pointdeltax  =  (long  float)(line_start|Xj  -  pointjXj); 
point  deltas  =  (long  Aoat)(line_start[Z)  -  point|Z|); 

linejength  =  (float)hypot(line  deltax,  line  deltas); 
dist  to  point  =  (float  )hy  pot  (pointdeltax,  point  deltas); 

interpolation  =  line_start(Y|  +  ((line  end(Y|  -  line_start(Y|) 
(dist  to  point/line  length)); 

return(interpolation); 

} 
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LIGHTOBXENT 


/*  this  is  file  lightorient.c  */ 

/* 


It  is  a  routine  that  computes  lighting  for  a  polygon  based 
upon  the  angle  between  the  Normal  vector  of  the  polygon 
and  the  direction  to  the  light  source. 

lightorient(xy*,ncoords,ax,ay,as,lx,ly,ls,colormin,colormax, colortouse) 
xy*()jS|  =  floating  coords  of  the  polygon, 
ncoords  =  number  of  coordinates. 

8LX,ay,az  =  interior  point  of  the  whole  object.  Used  to  determine 
outward  facing  normal  of  the  polygon.  This  is  the  same 
point  of  reference  that  would  be  used  for  backface 
polygon  removal. 

lx,ly,lz  =  vector  pointing  in  direction  of  the  light  source. 

colormin,  colormax  =  indices  used  for  the  colon  assigned  to  this 
polygon.  The  user  is  responsible  for  setting 
up  the  color  ramp. 

colortouse  =  returned  color  used  to  light  the  polygon. 

Note  the  routine  also  puts  the  polygons  out  ordered  counterclockwise 
with  respect  to  the  interior  point  for  ease  of  backface  polygon 
removal. 
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^include  <math.h> 
finclude  <gl  h> 

#define  MAXCOORDS  80 
#define  PIDIV2  1  570796527 

float  txyx|MAXCOORDS]|S];  /*  temp  coord  hold  */ 


lightorient(xyx,  ncoords,  ax, ay, ax, lx, ly,li, colormin, colorm  ax,  colortouse) 

float  xyi[j|3|; 
long  ncoords; 
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float  ax,ay,a«;  /*  interior  point  of  the  whole  object.  */ 
float  lx,ly,ls;  /*  direction  to  the  light  source  */ 
long  colormin.colormax;  /*  color  min/max  indices  */ 
long  *colortouse;  J*  color  used  to  light  the  polygon  (return  value)  */ 
{ 

long  ij;  /*  loop  temps  */ 

long  npoly  _orient();  /*  direction  test  function  */ 


float  vl[3j,v2|3); 

float  normal|3j; 
float  normalmag; 
float  lightmag; 
double  dotprod; 
float  radians; 


/*  vectors  used  to  compute 
the  polygon's  normal  */ 

/*  the  polygon’s  normal  */ 

/*  normal’s  magnitude  */ 

/*  magnitude  of  the  light  vector  */ 

/*  dot  product  of  N  and  L  *  j 

/*  angle  between  N  and  L  * / 


/*  check  the  number  of  coords  in  the  input  array  */ 
if(ncoords  >  MAXCOORDS) 

{ 

printf("LlGHTORIENT:  too  many  coords  passed  to  me!  =  %dO,ncoords) 
exit(l); 

} 

/*  orient  the  polygon  so  that  its  counterclockwise  with  respect 
to  the  interior  point  */ 

if(npoly_orient(ncoords,xyirax,ay,ai)  ==  1) 

{ 

/*  the  polygon  is  clockwise,  reverse  it.  */ 
for(i=0;  i  <  ncoords;  i=i+l) 

{ 

for(j=0;  j  <  3;  j=j+l) 

{ 

txy*(ij(jj  =  xytlncoorda-i-ljUj; 

} 

} 

for(i=0;  i  <  ncoords;  ++i) 
for  {j=0;  j  <  3;  ++j) 

xys[i||j]  =  txys[i|[j|; 
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/*  the  coordinates  are  ordered  counterclockwise  in  array  xys  */ 


/*  compute  the  norms!  vector  for  the  polygon  using  the  first 
three  vertices...*/ 

/*  compute  the  first  vector  to  use  in  the  computntion  */ 
vljOj  =  xy»j2]|0|  -  xyi|l]|0); 
vl|lj  =  xy*|2]|l)-xyi|l]|l); 
vlj2|  =  xy*|2]|2j  -  xy s(  1] (2] ; 

/*  compute  the  second  vector  to  use  in  computing  the  normal  */ 

v2(0|  =  xys(0||0]  -  xys|l|[Oj; 
v2(l|  =  xys|Ol|l|-xys|l||l|; 
v2|2|  =  xyi[0||2]  -  xyi|l]|2|; 

/*  the  normal  is  vl  x  v2  */ 
normaljO]  =  vl|l|*v2|2)  -  vl|2]*v2jlj; 
normaljlj  =  vl(2|*v2[0j  -  vijoj*v2[2|; 
normal[2]  =  vl|0]*v2|l|  -  vl|l)*v2[0j; 

/*  compute  the  magnitude  of  the  normal  */ 

normalmag  =  sqrt((normal[0j*normal[0|)  +  (normal|l]*normal[l])  + 
(normal[2|*normal[2])); 

/*  check  the  magnitude  of  the  normal  */ 
if(  normalmag  ==  0.0) 

{ 

normalmag  =  0.00001;  /*  a  small  number  */ 

} 

/*  compute  the  light  mag  */ 
lightmag  =  sqrt((lx*lx)  +  (Iy*ly)  +  (ls*U)); 

if(lightmag  --  0.0) 

{ 

lightmag  =  0.00001;  /*  a  small  number  */ 

} 

/*  compute  N  .  L  (normal  dot  product  with  the  light  source  direction)  */ 
dotprod  =  (normaljO)  *  lx)  +  (normaljlj  *  ly)  +  (normaI[2j  *  Is); 

dotprod  =  do.prod/(lightmag*normalmag); 

/*  dotprod  =  cos(theta)  of  the  angle  between  N  and  L. 

Convert  to  angle  in  radians  */ 
radians  =  acos(dotprod); 

/*  compute  the  color  we  should  use  */ 
if(-PIDIV2  <=  radians  Lb  radians  <=  PIDIV2) 

{ 


/*  if  the  angle  is  negative,  set  to  positive  */ 
if(radians  <  0.0) 

{ 

radiant  =  -radians; 

} 

'colortouse  =  ((colormax-colormin)/PIDIV2)*(PIDIVi-radians)+colormin; 

} 

else 

{ 

’colortouse  =  colormin; 

} 

/*  set  the  color  */ 
color  (‘colortouse); 

/*  draw  the  poly  */ 

/*  polf(ncoords,txy»);  */ 

} 


LINE  INTERSECTS 


finclude  "gl.h" 

#define  X  0 
#define  Z  2 
fdefine  NONE  0 
#define  INTERSECT  1 
#define  PROPER  2 


line  intersect2(startl,  endl,  start2,  end2,  intersect, 
intersect  type) 

float  startljSj,  endl|3),  start2|3j,  end2j3j,  intersect[3]; 
int  *  intersect  type; 


{ 

/*  given  two  lines  of  the  form  s  =  mx  +  b  and  s  =  nx  +  c, 
solving  for  x  when  the  s’s  are  equal  gives  x  =  (c-b)/(m-n). 

Then  solve  for  s  using  x  in  either  of  the  above  equations.  */ 

float  m,n,b,e; 

float  mini  x,  min2  x,  maxlx,  max2_x,  mini  s,  min2_s,  maxi  s,  max2  i; 

•intersect  type  =  PROPER; 

/*  slope  and  z  intercept  of  linel  */ 
if  (endljX]  !=  startljX])  { 

m  =  (endl|Zj  -  startl[Zj)/(endl(X]  -  startljX)); 

b  =  ((startljZj  -  endl (ZJ)/(endl (XJ  -  startljX)))  *  startljX)  +  startljZ); 
if  (end2[X]  !=  start2jX|)  {  /*  both  lines  are  non-vertical  */ 

/*  slope  and  z  intercept  of  line2  */ 
n  =  (end2jZ|  -  start2jZj)/(end2[X]  -  start2[XJ); 
c  =  ((start2[Zj  -  end2|Zj)/(end2|X]  -  start2[X)))  *  start2(X)  + 
start2|Z); 

if  (m  !=  n)  { 

intersect  jX]  =  (c-b)/(m-n); 
intersect|Z)  =  m*intersect[X)  +  b; 

} 

else  {  /*  both  lines  have  equal  slopes  * / 

‘intersecttype  =  NONE; 

} 

} 

else  {  /*  linel  is  non-vertical,  line2  is  vertical  */ 
intersectjX|  =  end2(X|; 
intersectjZ]  =  m*intersectjXj  +  b; 

} 

} 

else  { 
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if  (end2|X]  !=  start2[Xj)  {  /*  linel  is  vertical,  line2  is  non-vertical*/ 
/*  slope  and  s  intercept  of  line2  */ 
n  =  (end2|Z]  -  start2(Zj)/(end2|X|  -  start2[X|); 
c  =  ((start2[Z)  -  end2|Zl)/(end2[X)  -  start2|XD)  *  start2[X|  + 
start2[Z]; 

intersect|Xj  =  endl|X]; 
intersect|Z|  =  n*intersect[X]  +  c; 

} 

else  {  /*  both  lines  are  vertical  */ 

•intersect  type  =  NONE; 

} 

} 

if  (‘intersect  type  !=  NONE)  { 

/*  see  if  the  intersection  is  proper,  or  if  only  the  extensions  of  the 
line  segments  intersect  */ 
if  (startl(X)  <  endl(XJ)  { 
mini  x  =  startljX); 
maxi  x  =  endl[X]; 

} 

else  { 

minl_x  =  endl(X]; 
maxi  x  =  startl[X|; 

} 

if  (start![Z|  <  endl(ZJ)  { 
mini  s  =  startl(Z); 
maxis  =  endl(Z]; 

} 

else  { 

min  I  s  -  endl[Z|; 
maxi  i  =  startljZ); 

>  ; 

if  (start2[X|  <  end2(X|)  { 
min2_x  =  start2[X|; 
max2  x  =  end2(X|; 

} 

else  { 

min2_x  =  end2[Xj; 
max2  x  =  start2[X]; 

} 

if  (start2(Z|  <  end2jZj)  { 
min2_s  =  start2[Z|; 
max2  i  =  end2(Zj; 

} 

else  { 

min2_s  =  end2|Z]; 
max2_s  =  start2jZ|; 

} 
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if  ((intersect|X|  <=  max  lx)  kk  (intersect|X]  < 
(intenectjXj  >=  min  lx)  kk  (intmeetjX)  > 
(inten«ctjz|  <=  mul  ij  kk  (intemct|Z|  < 
( intersect (Z)  >  =  mini  s)  kk  (interaect[Zj  >  = 

‘intersecttype  =  PROPER; 

} 

else  { 

*intersect_type  =  INTERSECT; 

} 

} 

} 


:=  max2_x)  kk 
-  min2_x)  kk 
=  max2_s)  kk 
min2_s))  { 
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MAKENAVBOX 


/*  drawnavbox.c  -  this  function  is  called  by  the  FOG-M  missile  simulator  to 
build  an  object  on  top  of  the  contour  map  in  the  upper  right-hand  corner 
of  the  screen.  Navbox  contains  the  direction  arrow  and  view  box  in  red.  */ 

#include  "gl.h" 

#include  "fogm.h" 
finclude  "device.h" 

drawnavbox(navbox,  arrowtag) 

Object  ‘navbox; 

Tag  ‘arrowtag; 

{ 

‘navbox  =  genobjQ;  /*  create  the  navigation  contol  and  display  object  */ 

m  akeobj  ( *  nav  box ) ; 

if  (TV)  viewport(475, 635, 323,474); 

else  viewport(768, 1023, 512, 767);  /*  upper  right  hand  corner  of  screen  */ 
pushmatrix();  /*  draw  arrow  in  feet  coordinates  */ 

ortho2(- 10.0, 10.0  +  NUMXGRIDS*FEETPERGRID,  -10.0, 

-10.0-  NUM2GRIDS*FEETPERGRID); 

color(BLACK); 

clear(); 

color  (128); 

‘arrowtag  =  gentag(); 
maketag(*  arrowtag); 
move2(0.0,0.0); 
draw2(0. 0,0.0); 
draw2(0.0,0.0); 
move2(0. 0,0.0); 
draw2(0.0,  0.0); 

rect(0. 0,0. 0,0. 0,0.0);  /*  view  box  */ 

popmatrix(); 

closeobj(); 

} 


MAKEINDBOX 


/*  makeindbox.c  is  a  function  that  create*  an  object  that  displays  the  control 
idicators  for  the  FOG-M  missile  simulation  */ 

^include  "gl.h" 

#include  "fogm.h" 

makeindbox(indbox,headingtag,elevtag,altmsltag,speedtag,soomtag,tilttag,paatag,desigtag) 
Object  ‘indbox; 

Tag  *headingtag,  *elevtag,  *speedtag,  *  loom  tag,  ‘tilttag,  *  pan  tag,  *desigtag; 

Tag  *altmsltag; 

{ 

‘indbox  =  genobj(); 

makeobj(*indbox); 

if  (TV)  viewport(475, 635, 162,322); 

else  viewport(768, 1023, 256, 511);  /*  middle  box  on  side  of  screen  */ 

pushmatrixQ; 

ortho2(0.0, 255. 0,0. 0,255.0);  /*  use  screen  sised  coordinates  */ 

color(854);  /*  clear  the  window  */ 

clear(); 

linewidth(2); 

color(BLACK); 

recti(0, 0,255,255);  /*  outline  box  */ 

color(YELLOW);  /*  print  labels  for  readouts  */ 

cmov2i(  10,240); 

charstr("SPEED"); 

cmov2i(55,225); 

charstrC'kts"); 

cmov2i(90,240); 

charstr("HEADlNG"); 

circ(140. 0,232.0, 3.0);  /*  "degree"  symbol  */ 

cmov2i(180,240); 

charstr("Alt  AGL");  /*  AGL  =  above  ground  level  */ 

cmov2i(225,225); 

charstr("ft"); 

cmov2i(  180,200); 

charstr("Alt  MSL");  /*  MSL  =  mean  sea  level  */ 

cmov2i(225,185); 

charstr("ft"); 

cmov2i(50,130); 

charstr("ZOOM"); 

move2i(45,200);  /*  draw  slider  bar  frame  */ 

draw2i(25,200); 

draw2i(25,70); 

draw2i(45,70); 

cmov2i(  15,196); 


char»tr("8");  /*  label  »lider  bar  value*  */ 

cmov2i(6,170); 

charstr("15"); 

cmov2i(6,144); 

charstr{"25"); 

cmov2i(6,118); 

charstr("35"); 

cmov2i(6,92); 

charstr("45"); 

cmov2i(6,66); 

charstr("55"); 

color(  WHITE);  /*  readout*  in  white...  */ 

cmov2i(  10,225);  /*  initiali*e  to  dummy  values  */ 

‘speedtag  =  gentag(); 
maketag(  *  speedtag) ; 

charstr("  200");  J*  speed  */ 

cmov2i(  108,225); 

*headingtag  =  gentag(); 

maketag^headingtag); 

charstr("  0");  /*  heading  */ 

cmov2i(180,225); 

•elevtag  =  gentagQ; 
maketag(*elevtag); 

charstr("1000");  /*  altitude  above  ground  level  */ 

cmov2i(  180,185); 

*  altmsltag  =  gentagQ; 
m  aketag  ( *  altmsltag ) ; 

charstr("1000");  /*  altitude  from  mean  sea  level  *  j 

color(EED); 

**oomtag=  gentagQ;  /*  indicator  for  soom  slider  bar  */ 

maketag  ( *  loom  tag) ; 

move2(28. 0,135.0); 

rdr2(10. 0,5.0); 

rdr2(0.0,-10.0); 

rdr2(-10. 0,5.0); 

popmatrixQ; 

if  (TV)  viewport(0, 474,0, 474);  /*  reset  for  heads-up  display  */ 

else  viewport(0,767, 0,767); 

pushmatrixQ; 

ortho2(0.0, 767.0, 0.0, 767.0);  /*  use  screen  *i*ed  coordinate*  */ 

color(  WHITE); 


I 

I 

» 

t 

» 

J  if  (TV)  linewidth(2); 

else  linewidth(l); 

rectfi(S65,S70,370,375);  /*  draw  center  of  crosshairs  */ 

rectfi(396,370,401,375); 

rectfi(365,391,370,396); 

rectfi(396,391,401,390); 

|  move2i(0,S83); 

draw2i(360,S8S);  /*  draw  crosshairs  */ 

move2i(40e,383); 

draw2i(767,S83); 

move2i(S83,0); 

draw2i(383,365); 

move2i(383,401); 

draw2i(383,767); 

linewidth(2); 

move2i(30,50);  /*  draw  TILT  slider  bar  frame  */ 

draw2i(40,50); 

draw2i(40,680); 

draw2i(30,680); 

cmov2i(0,678); 

char9tr("  +  25");  /*  label  slider  bar  values  */ 

cmov2i(0,613); 

charstr("+20"); 

move2i(30,617); 

draw2i(40,6l7); 

cmov2i(0,550); 

charstr("  +  15"); 

move2i(30,554); 

draw2i(40,554); 

cmov2i(0,487); 

charstr("  +  10"); 

move2i(30,491); 

draw2i(40,491); 

cmov2i(0,424); 

charstr("  +5"); 

move2i(30,428); 

draw2i(40,428); 

cmov2i(0,361); 

charstr("  0"); 

move2i(30,385); 

draw2i(40,365); 

cmov2i(0,298); 

charstr("  -5"); 

move2i(S0,302); 

draw2i(40,302); 

cmov2i(0,235); 

charstrC'-lO"); 

move2i(30,239); 

draw2i(40,239); 
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cmov2i(0,172); 

charstr{"-15"j; 

move2i(30,l76); 

draw2i(40,l76); 

cmov2i(0,109); 

charttrC^O"); 

move2i(SO,HS); 

draw2i(40,113); 

cmov2i(0,46); 

charstr("-25"); 

‘tilttag  =  gentagQ;  /*  indicator  for  TILT  slider  bar  * / 

maketag(*  tilttag); 

move2  (42. 0,365.0); 

rdr2(  10.0, -5.0); 

rdr2(  0.0,10.0); 

rdr2(-8.0,-4.0); 

rdr2(  6.0, -3.0); 

rdr2(  0.0,  4.0); 

rdr2(-2.0,-1.0); 

rdr2(  1.0, -1.0); 

move2i(120,15);  /*  draw  PAN  slider  bar  frame  */ 

draw2i(120,25); 

draw2i(750,25); 

draw2i(750, 15); 

cmov2i(107,3); 

charstr("-25");  /*  label  slider  bar  values  */ 

cmov2i(170,3); 

charstr("-20"); 

move2i(183,15); 

draw2i(183,25); 

cmov2i(233,3); 

charstr("-15"); 

move2i(246,15); 

draw2i(246,25); 

cmov2i(296,S); 

charstr(H-10"); 

move2i(309,15); 

draw2i(309,25); 

cmov2i(36S,3); 

charstr("-5"); 

move2i(372,15); 

draw2i(372,25); 

cmov2i(431,3); 

charstr("0"); 

move2i(435,15); 

draw2i(435,25); 

cmov2i(494,3); 

charstr("+5"); 

move2i(498,15); 

draw2i(498,25); 


cmov2i(552,3); 

charstr("  +  10"); 

move2i(561,15); 

draw2i(56l,25); 

cmov2i(615,3); 

charstr("  +  15"); 

move2i(624,15); 

draw2i(624,25); 

cmov2i(078,3); 

charstr("-*-20"); 

move2i(687,15); 

draw2i(687,25); 

cmov2i(741,3); 

charatr("  +  25"); 

‘pantag  =  gentag();  /*  indicator  for  PAN  slider  bar  * / 

maketag(*pantag); 

move2(4S5. 0,27.0); 

rdr2(  5  0,10.0); 

rdr2(-10  0,  0.0); 

rdr2(  4  0, -8.0); 

rdr2(  3  0,  6.0); 

rdr2(  -4.0,  0.0); 

rdr2(  10,-20); 

rdr2(  1  0,  1.0); 

move2i(0,30);  /*  designate/reject  box  */ 

draw2i(  100,30); 
draw2i(  100,0); 

‘desigtag  =  gentag(); 
maketag(*desigtag); 
cmov2i(10,10); 
charstr("DESIGNATE"); 


popmatrix(); 

closeobj(); 


MAKEENSTRBOX 


/*  makeinstrbox.c  •  this  function  builds  an  object  that  contains  an  instruction 
summary  for  the  FOG-M  missile  simulation  */ 

#include  "gl.h" 

#include  "fogm.h" 

makeinstrbox(instrbox) 

Object  *instrbox; 

{ 

*instrbox  =  genobjQ; 

makeobj(*instrbox); 

if  (TV)  viewport(475, 835, 0,161); 

else  viewport(768, 1023, 0,255);  /*  box  is  in  lower  right  hand  corner  */ 

pushmatrixQ; 

ortho2(0.0, 255. 0,0.0, 255.0);  /*  use  screen-sised  coordinates  */ 

color(85l);  /*  use  a  medium  green  */ 

clear(); 

linewidth(2); 

color(852);  /*  use  light  brown  */ 

rectfi(l0,20,110,195);  /*  draw  the  mouse  control  box  */ 

rectfi(135,80,245,I95);  /*  draw  the  dial  control  box  */ 

color(BLACK);  j*  outline  controls  */ 

recti(  10,20, 110, 195); 
recti(  135,80,245, 195); 
recti(0, 0,255, 255); 

color(BLACK); 

cmov2i(60,230); 

charstr("C  O  N  T  R  O  L  S"); 

cmov2i(37,200); 

charstr("MOUSE”); 

cmov2i(172,200); 

charstr("DIALS"); 

cmov2i(25,60); 

charstr("TILT''); 

move2i(70,62);  /*  draw  arrow  */ 

draw2i(75,55); 

draw2i{75,75); 

draw2i(70,88); 

move2i(75,75); 

draw2i(80,68); 

move2i(75,55); 

draw2i(80,62); 
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cmov2i(25,30); 

charstr(''PAN"); 

move2i(67,40);  /*  draw  arrow  */ 

draw2i(60,35); 

draw2i(80,S5); 

draw2i(73,40); 

move2i(80,35); 

draw2i(73,30); 

move2i(60,S5); 

draw2i(07,30); 

color(853);  /*  dark  brown  */ 

rectfi(20, 85,40, 185);  /*  draw  mouse  buttons  * 

rectfi(50,85,70,185); 
rectfi(80, 85,100, 185); 

color(BLACK);  /*  outline  buttons  */ 

recti(20,85,40,185); 

recti(50, 85,70, 185); 

recti(80, 85, 100,185); 

color  (853); 

circfi(l60,165,20);  /*  draw  dials  */ 

circfi(l60, 110,20); 
circfi(220, 165,20); 
circfi  (220, 1 10,20) ; 

color(BLACK);  /*  outline  dials  */ 

circi(  160, 165,20); 

circij  160, 110,20); 

circi(220, 165,20); 

circij 220, 1 10,20) ; 

color(WHITE); 

cmov2i(147,160); 

charstr("SPD");  /*  label  dials  */ 

cmov2i(147,106); 

charatr("DIR"); 

cmov2i(207,106); 

charatr("ALTn); 

cmov2i  (207 , 160) ; 

charstr("CLR"); 

cmov2i(25,170); 

charstr("Zn);  /*  label  mouse  buttons  */ 

cmov2i(25,158); 

charstr("0"); 

cmov2i(25,146); 

char»tr("0"); 

cmov2i(25,134); 

charstr("M"); 

cmov2i(25,110); 

charatr(nI"); 

cmov2i(25,98); 

charstr(”N"); 
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cmov3i(55,l70) 

-h«tr("Dw); 

cmov3i(65,l&8): 

char»tr("E"); 

cmov2i(55,146) 

charstr(NSn); 

cmov2i(55,134) 

ch«mr("I"); 

cmov2i(55,122) 

charatr(NGtt); 

cmov2i(85,170) 

charstr("Z"); 

cmov2i(85,158) 

char»tr(nO"); 

cmov2i(85,146) 

charstr("0"); 

cmov2i(85,134) 

charatr(”M"); 

cmov2i(85,110) 

charstif'O"); 

cmov2i(85,98); 

charstr("U"); 

cmov2i(85,86); 

charstr("T"); 

popm&trixQ; 

closeobjQ; 


MAKEMAP 


/*  makemap.c  -  this  function  is  culled  by  the  FOG-M  missile  simulutor  to 
build  un  object  containing  u  contour  map.  The  map  is  used  for  the  full 
screen  display  in  prelaunch,  and'  in  the  upper  right  corner  of  the  flight 
display  in  fogm.  */ 

^include  "gl.h" 

$  include  "fogm.h" 

^include  "device. h" 

makemap(contour) 

Object  *contour; 

{ 

short  i,  j,  elev,  length,  lastcolor,  breakpt[l&]; 
int  colour; 

extern  short  gridpixel[lOO](lOOj;  /*  terrain  elevations  tt  vegetation  */ 

/*  compute  elevations  where  color  changes  should  occur  "/ 

for  (i  as  1;  i  <  1®;  i++)  breakpt|i-l|  =  (((MAX  -  MIN)  /  18  )  *  i)  +  MIN; 

"contour  =  genobjQ;  /*  create  the  navigation  contol  and  display  object  */ 
makeobj  ("contour); 
view  port  (0,767 ,0,787); 
pushmatrix(); 

ortho2(0.0, 100.0,0.0, 100.0);  /*  use  array  index  space  */ 

color(BLACK); 

clear(); 

lastcolor  =  BLACK; 
linewidth(8); 

for  (i=0;  i  <  100;  ++i)  (  /*  draw  column  i  "/ 

move2i(i,0);  /*  start  at  bottom  of  column  */ 

length  =  0;  /*  #  adjacent  points  of  the  same  color  */ 

for  (j  =  0;  j  <  100;  ++j)  {  /*  for  each  row  in  column  i  */ 

elev  =  gridpixel[j](i]  It  elev_maak;  /*  mask  off  veg  code  "/ 

if  (elev  <  breakpt(Oj)  colour  =  16;  /*  assign  green  colors  */ 

else  if  (elev  <  breakptflj)  colour  =  17; 

else  if  (elev  <  breakpi[2])  colour  =  18; 

else  if  (elev  <  breakptjsj)  colour  =  19; 

else  if  (elev  <  breakpt[4|)  colour  =  20; 

else  if  (elev  <  breakptjflj)  colour  =  21; 

else  if  (elev  <  breakptjoj)  colour  =  22; 

else  if  (elev  <  break pt [7])  colour  =  23; 

else  if  (elev  <  breakptjsj)  colour  =  24; 

else  if  (elev  <  breakpt(9])  colour  =  25; 

else  if  (elev  <  breakptjlOj)  colour  =  26; 

else  if  (elev  <  break ptjllj)  colour  =  27; 

else  if  (elev  <  breakptjl2])  colour  =  28; 
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else  if  (elev  <  break  pt|  13])  colour  =  29; 
else  if  (elev  <  breakpt[14j)  colour  =  SO; 
else  colour  =  SI; 

/*  if  v  eg -code  a  0  (i.e.  veg  <  1  meter)  shift  to  brown  colors  */ 
if  (!((gridpixel(j)(ij  >>  IS)  k  veg_mssk))  colour  +=  10; 

if  (colour  ==  lastcolor)  length++;  /*  don’t  draw  yet  */ 
else  {  /*  draw  now  that  color  has  changed  */ 

color  (lastcolor); 
rdr2i(0,  length); 

lastcolor  =  colour;  /*  reset  for  new  draw  */ 

length  =  1; 

} 

}  /*  end  for  j  */ 

color  (colour);  /*  draw  last  (top)  line  */ 

rdr2i(0,  length); 

}  /*  end  for  i  */ 

if  (!TV)  { 

color(BLACK);  /*  draw  grid  on  top  of  map  */ 

linewidth(l); 

for  (i  =  10;  i  <  100;  i+=10)  {  /*  draw  interior  lines  */ 
move2i(i,0);  /*  horisontals  */ 

draw2i(i,100); 

move2i(0,i);  /*  verticals  */ 

draw2i(100,i); 

) 

} 

linewidth(2);  /•  draw  exterior  border  */ 

rect(0.0,0.0, 100.0, 100.0); 

popmatrixQ; 

closeobj(); 
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MAKESCREKNS 


/*  makescreens.c  -  builda  graphical  objects  for  prelaunch’*  inatructional 
screen*  and  readout  boxes.  */ 

4 include  "gl.h" 

# include  "device. h" 
f  include  "fogm.h" 

makescreens(obj,tag) 

Object  obj[7|; 

Tag  tag[6(; 

{ 

obj|INSTRj  =  genobjQ;  /*  object  for  pre-launch  instructions  */ 

makeobj(obj[INSTRj); 

if  (TV)  viewport(475, 635,239,474); 

else  viewport(767, 1023, 385, 767); 

pushmatrix(); 

ortho2(0.0, 255.0,0.0, 384.0); 

color(CYAN); 

clear(); 

color(BLUE); 

rectfi(10, 10,245,374); 

color(  WHITE); 

cmov2i(30,340); 

charstr("PRE-LAUNCH  INSTRUCTIONS"); 
cmov2i(25,S00); 

charatr("l.  PRESS  LEFT  MOUSE"); 
cmov2i(52,285); 

charstr("BUTTON  TO  LOCK  IN"); 
cmov2i(52,270); 

charstr("LAUNCH  POSITION"); 
cmov2i(25,220); 

charstr("2.  PRESS  RIGHT  MOUSE"); 
cmov2i(52,205); 

charstr("BUTTON  TO  LOCK  IN"); 
cmov2i(52,190); 

charstr("TARGET  LOCATION"); 
cmov2i(25,140); 

charstr("3.  PRESS  MIDDLE  MOUSE"); 
cmov2i(52,125); 

charstr("BUTTON  TO  LAUNCH"); 
cmov2i(25,  75); 

charstr("4.  PRESS  ALL  THREE"); 
cmov2i(52,  60); 

charstr("BUTTONS  TO  EXIT"); 

popmatrix(); 

closeobj(); 


/*  define  object  for  displaying  uaer  input  for  misaile  launch 

position  and  target  location.  Also  displays  computed  heading 
and  distance  to  target  */ 

obj(STATS)  =  genobjQ; 

makeobj(obj]STATS]); 

if  (TV)  view port(47S, 035,0,238); 

else  viewport(767, 1023, 0,384); 

pushmatrixQ; 

ortho2(0.0, 255.0, 0.0, 384.0); 

color(CYAN); 

clear(); 

color  (BLUE); 

rectfi( 10, 10,245,374) ; 

color(  WHITE); 

cmov2i(30,340); 

charstr("PRE-LAUNCH  STATISTICS"); 
emov2i(25,260); 

charstr("LAUNCH  POSITION:  10SFQ"); 

cmov2i(70,235); 

charstr("X  COORD:  "); 

cmov2i(70,220); 

charstr("Y  COORD:  "); 

cmov2i(  170,235); 

tag[LAUNCH]  =  gentagQ; 

maketag(tag[LAUNCH]); 

charstr("  "); 

cmov2i(  1 70,220) ; 

charstr("  "); 

cmov2i(25,180); 

charstr("TARGET  LOCATION:  10SFQ"); 

cmov2i(70,155); 

charstr("X  COORD:  '•); 

cmov2i(70,140); 

charstr(nY  COORD:  "); 

cmov2i(170,155); 

tag(TARGETJ  =  gentag(); 

maketag(tag|TARGET]); 

charstr("  "); 

cmov2i(170,140); 

charstr("  "); 

cmov2i(25,100); 

charstr("HEADING:  "); 

cmov2i(25,80); 

charstr("DISTANCE:  "); 

cmov2i(106,100); 

tag(HEAD)  =  gentag(); 

maketag(tag[HEAD|); 

charstr("  "); 

cmov2i(  115,60); 

charstr("  "); 

popmatrix(); 
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closeobjQ; 

/*  define  object  for  lines  4c  circles  showing  fiightpsth  on  contour  map  */ 

obj[FLTPATH]  =  genobjQ; 

makeobj(objjFLTPATH)); 

pnshmatrix(); 

if  (TV)  viewport^, 474, 0,474); 
else  viewport(0, 767 ,0,767); 

ortho2(0. 0,100. 0,0. 0,100.0); 

color(BLACK); 
clear(); 
color  (64); 
linewidth(S); 

t&gjMISSILE]  =  gentag(); 
maketag  (tag  (MISSILE) ) ; 
circf(0.0,0.0,0.0); 
move2(0.0,  0.0,  0.0); 
draw2(0.0,  0.0,  0.0); 
color(128); 

tag|TGT]  =  gentag(); 
maketag(tag{TGTj); 
circf(0. 0,0.0, 0.0); 
popmatrix(); 
doseobjO; 

/*  define  object  for  displaying  first  screen  of  operator  instructions  */ 

obj  [SCREEN  1]  =  genobj(); 
makeobj(obj|SCREENl]); 

color(BLUE);  /*  set  background  color  */ 

clear  (); 

color  (RED); 

linewidth(lO); 

recti(0,0, 1023,767) ; 

linewidth(l); 

color(  WHITE); 

cmov2i(420,500); 

charstr("  WELCOME"); 

cmov2i(420,450); 

charstr("TO  THE"); 

cmov2i(S20,400); 

charstr("FIBER-OPTICALLY  GUIDED  MISSILE"); 

cmov2i(420,350); 

charstr(»(FOG-M)"); 

cmov2i(410,300); 

charstr("SIMUL  ATION") ; 

cmov2i(310,100); 

charstr("PRESS  MIDDLE  MOUSE  BUTTON  TO  CONTINUE..."); 
cmov2i(315,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 
doseobj(); 
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/*  define  object  for  displaying  second  screen  of  operator  instructions  */ 


obj|SCREEN2]  =  genobjQ; 
makeobj(obj(SCREEN2j); 

color(BLUE);  /*  set  bsckground  color  */ 

clesr(); 

linewidth(lO); 

color(RED); 

recti(0,0, 1023,767); 

linewidth(l); 

color(  WHITE); 

cmov2i(2 10,600) ; 

charstr("THE  FOG-M  PROGRAM  PROVIDES  A  SIMULATED  MISSILE  LAUNCH  AND"), 
cmov2i(210,575); 

charstr("OUT-THE- WINDOW  VIEW  OF  THE  TERRAIN  AS  SEEN  FROM  THE  OPERATOR’S"); 
v  cmov2i(210,550); 

chsrstr("CONSOLE  ON  THE  GROUND."); 
cmov2i(2l0,500); 

charstr("THE  GENERAL  AREA  FOR  THIS  FLIGHT  SIMULATION  IS  FT  HUNTER  LIGGETT"); 
cmov2i(210,475); 

ch«rstr("CALIFORNIA  AND  VICINITY."); 
cmov2i(210,425); 

charstr("THE  SPECIFIC  TEST  AREA  IS  A  10  KILOMETER  REGION  DESIGNATED  BY"); 
cmov2i(2 10,400); 

chnrstr( "UNIVERSAL  TRANSVERSE  MERCATOR  (UTM)  GRID  COORDINATES  10SFQ58."); 
cmov2i(300,100); 

chnrstr ( "PRESS  MIDDLE  MOUSE  BUTTON  TO  CONTINUE,"); 
cmov2i(305,8S); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 
doseobj(); 

/*  define  object  for  displaying  third  screen  of  operator  instructions  */ 

obj|  SCREENS]  =  genobjQ; 
makeobj(obj[SCREEN3]); 

color(BLUE);  /*  set  background  color  */ 

clearQ; 
linewidth(lO); 
color(RED); 
recti(0, 0,1023, 767); 
linewidth(l); 
color(  WHITE); 
cmov2i(S85,650); 

charstr("PRE-LAUNCH  ORIENTATION"); 
cmov2i(200,600); 

charstr(”l.  WHEN  THE  PRE-LAUNCH  PHASE  OF  THE  FOG-M  SIMULATION  BEGINS,  A"); 
cmov2i(200,585); 

charstr( "2-DIMENSIONAL  CONTOUR  MAP  OF  THE  TEST  AREA  (UTM  10SFQ58)  WILL  BE"); 
cmov2i(200,570) ; 

charstr(  "DISPLAYED  ON  THE  OPERATOR  CONSOLE.  TWO  CONTROL  PANELS  CONTAINING"); 
cmov2i(200,555); 

charstr(  "PRE-LAUNCH  INSTRUCTIONS  AND  CURRENT  LAUNCH  STATISTICS  WILL  ALSO"); 
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cmov2i(200,540); 
chantr("BE  DISPLAYED."); 
cmov2i(200,490); 

chantr("2.  THE  OPERATOR  WILL  BE  REQUIRED  TO  PROVIDE  TWO  CRITICAL  DATA"); 
cmov2i(200,475); 

chamr("ITEMS  TO  THE  LAUNCH  CONTROL  SYSTEM;  INITIAL  LAUNCH  POSITION  AND"); 
cmo  v2i(200,460) ; 

charstr( "TARGET  LOCATION."); 
emov2i(200,4 10) ; 

charstr("S.  TO  DEFINE  INITIAL  LAUNCH  POSITION,  MOVE  CURSOR  OVER  DESIRED"); 
cmov2i(200,395); 

charstr("LOCATION  (REFER  TO  LAUNCH  STATISTICS  CONTROL  PANEL  TO  VIEW  THE"); 
cmov2i(200,380); 

charstr( "CURRENT  UTM  GRID  COORDINATES).  PRESS  LEFT  MOUSE  BUTTON  TO  LOCK"); 
cmov2i(2OO,305); 

char»tr("IN  LAUNCH  POSITION.");  * 
cmov2i(200,315); 

charstr("4.  TO  DEFINE  TARGET  LOCATION,  MOVE  CURSOR  OVER  DESIRED  LOCATION"); 
cmov2i(200,300) ; 

charstr("  (REFER  TO  LAUNCH  STATISTICS  CONTROL  PANEL  TO  VIEW  CURRENT  UTM"); 
cmov2i(200,285) ; 

charstr("GRID  COORDINATES).  PRESS  RIGHT  MOUSE  BUTTON  TO  LOCK  IN  TARGET"); 
cmov2i(200,270); 

charstif'LOCATION.  THE  BLUE  LINE  DISPLAYS  THE  PROJECTED  FLIGHT  PATH.  THE"), 
cmov2i(200,255); 

charstr( "MISSILE  WILL  FLY  AT  A  CONSTANT  VELOCITY  AND  HEADING.  THE  LAUNCH"); 
cmov2i(200,240); 

charstr ("STATISTICS  CONTROL  PANEL  WILL  DISPLAY  COMPUTED  MISSILE  HEADING"); 
cmov2i(200,225); 

char»tr("IN  DEGREES  (0  DEGREES  DUE  NORTH)."); 
cmov2i(240,100); 

charetr("PRESS  MIDDLE  MOUSE  BUTTON  TO  MOVE  INTO  PRE-LAUNCH  PHASE,"); 
cmov2i(326,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 
clos«obj(); 


MAKETANK 


f  include  "gl.h" 

#  include  "fogm.h" 

maketank(item) 
Object  *item; 

{ 


long  points  =  4,  bigpointi  =  8; 
float  parray(8]fS|; 
float  lx,ly,ls; 

long  cmin  =  MIN  TGT  COLOR,  emu  =  MAX  TGT  COLOR,  cl 

lx  =  400.0  *  41.01;  /*  direction  of  lightsource  */ 
ly  =  6000.0; 

Is  =  200.0  *  (-41.01); 


*item=genobj(); 

makeobj(*item); 

/*  draw  right  side  of  tank  CCW  */ 
parray|0|[0)  =  -10.0; 
parray[0]jlj  =  6.0; 
parray|0](2]  =  -5.0; 
parrayil](0]  =  -15.0; 
parray[l]|l]  =  4.0; 
parray[l||2]  =  -5.0; 
parray(2](0)  =  -15.0; 
parray|2]|l)  «  2.0; 
parray|2]|2)  =  -5.0; 
pnrrayjsjjo]  =  -10.0; 
parrayjsjjl)  =  0.0; 
parray(Sj(2)  =  -5.0; 
parray|4](0j  =  10.0; 
paiTayj4j(l|  =  0.0; 
parray(4|[2]  =  -5.0; 
parray|5||0)  =  15.0; 
parTayi5j[lj  =  2.0; 
pan-ay  [5]  [2]  =  -5.0; 
parrayjejjoj  =  15.0; 
parray(6||l]  =  4.0; 
parrayj«j|2|  =  -5.0; 
pairay[7j|0)  =  10.0; 
parray[7)jl  j  =  6.0; 
parray[7j|2|  =  -5.0; 

Iightorient(parray,bigpointsl0.0l0.0,0.0llx,lyllslcinia,cmax,lccl); 

color(cl); 


polf(bigpoinU,puT&y); 

/*  front  of  tank  CW  •/ 
parmy|0][0]  =  15.0; 
parrayjojjlj  =  5.0; 
parray(oj(2j  =  -5.0; 
parray  jljjoj  =  15.0; 
p*rr»y|l]|l}  =  5.0; 
parrayjlj(2j  =  -5.0; 
parray  j2]|oj  =  15.0; 
parray[2][l]  =  5.0; 
parray(2)[2]  =  5.0; 
parrayjsjjoj  =  15.0; 
parray|sjjl]  =  5.0; 
parray[S][2]  =  5.0; 

lightorientlparray.points.O.O.O.O.O.O.Ujiy.b.cmb.cmax.tel); 

color(cl); 

polf (points, parray ) ; 

/*  draw  left  side  of  tank  CW  */ 
parray  ,01(0]  =  10.0; 
parray(0](l]  =  6.0; 
parray(oj[2]  =  5.0; 
parray  [ljjoj  =  15.0; 
parrayjljjlj  =  4.0; 

Parray[lj(2j  =  5.0; 
parray(2]Joj  =  15.0; 
parray(2j[lj  =  2.0; 
parray  [2|  [2]  =  5.0; 
parrayjsjjo]  =  10.0; 
parrayjsjjlj  =  0.0; 
parray(sj(2]  =  5.0; 
parrayjljjoj  =  -10.0; 
parrayjljjlj  =  0.0; 
parrayj4j(2j  =  5.0; 
parrayj5jjoj  =  -15.0; 
parray|5jjlj  =  2.0; 
parray(5j(2]  =  5.0; 
parTayjejjoj  =  -15.0; 
parray  jejjlj  =  4.0; 
parrayj«jj2]  =  5.0; 
parray  j7j(0j  =  -10.0; 
parrayj7jjlj  =  5.0; 
parrayj7j|2j  =  5.0; 

Iightorient(psrray,bigpoints,0.010.0,0.0,lx,ly,li,einin,cinax,ltcl); 

color(cl); 

polf(bigpoints,  parray); 

I*  back  of  tank  CCW  */ 
parray  |0][0]  =  -15.0; 
parrayjojjlj  =  4.0; 
parrayjoj(2j  =  5.0; 
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parray)l|[0)  =  -15.0; 
parray|l)|l]  =  2.0; 
parray|lj|2j  =  5.0; 
parray  [2  jjoj  =  -15.0; 
parray[2)|l)  =  2.0; 
pairay(2|j2j  =  -5.0; 
parrayisjloj  =  -15.0; 
parrayjsjjlj  =  4.0; 
parray(Sj(2|  =  -5.0; 

lightorient(parray, points, 0.0, 0.0, 0.0, lx, ly  ,1s, cmin, cmax,&cl); 

color  (cl); 

polf (poin  ts,  parray ) ; 

/*  top  middle  of  tank  body  CCW  */ 

parray[0||0]  =  -10.0; 

parray(oj|lj  =  6.0; 

parray  jo)  |2j  =  -5.0; 

parrayjljjoj  =  -10.0; 

parrayjljjlj  =  fl.O; 

parrayjljj2)  =  5.0; 

parrayj2jjoj  =  10.0; 

parray|2)[lj  =  6.0; 

parray  [2]  [2]  =  5.0; 

parray  |sj  [0)  =  10.0; 

parTayjsjjlj  =  6.0; 

parray  jsj(2]  =  -5.0; 

Iightorient  (parray  .points, 0.0, 0.0, 0.0, lx, ly, Is, cmin  ,cmax,  tel ) ; 
color(cl); 

polf(points, parray); 

/*  top  front  of  tank  body  CCW  */ 

parray|0)]0]  =  10.0; 

parrayjojjlj  =  6.0; 

parTay[ojj2j  =  -5.0; 

parrayjljjoj  =  10.0; 

parrayjljjl]  =  6.0; 

parrayjljj2j  =  5.0; 

parray  j2jjoj  =  15.0; 

parray(2j|lj  =  4.0; 

parrayj2jj2j  =  5.0; 

parrayjsjjoj  =  15.0; 

parrayjsjjlj  •-  4.0; 

parray  (S][2]  =  -5.0; 

Iightorient  (parray,  points,  0.0, 0.0, 0.0,  lx,  ly,  Is,  cmin,  cmax,&cl); 
color  (cl); 

polf(points, parray); 

/*  top  back  of  tank  body  CCW  */ 
parray[0](0]  =  -10.0; 
parray  [oj  jlj  =  6.0; 
parray  jo)  |2]  =  -5.0; 
parrayjljjoj  =  -15.0; 


parray(l]{l]  =  4.0; 
parray]lj[2]  =  -5.0; 
pajTay|2j[0]  =  -15.0; 
parray(2j(l]  =  4.0; 
parray|2]|2)  =  5.0; 
parrayjsjjoj  =  -10.0; 
parray  ]3J(lj  =  0.0; 
parray|Sj[2j  =  5.0; 

lightorient(paiTay, points, 0.0, 0.0, 0.0, lx, ly,li,cmin,cmax,l£cl); 

color(cl); 

polf(points,parray); 

/*  bottom  middle  of  tank  CW*/ 
p  array  (0j[0j  =  -10.0; 
parrayjojjlj  =  0.0; 
parray[oj[2)  =  -5.0; 
parrayjljjoj  =  10.0; 
parrayjljjl]  =  0.0; 
parray|l][2]  =  -5.0; 
parray(2jjoj  =  10.0; 
parray[2||lj  =  0.0; 
parray|2||2]  =  5.0; 
paiTay[5j[0]  =  -10.0; 
paiTayjs|(l)  =  0.0; 
parray|S][2]  =  5.0; 

Iigktorient(parraylpoints,0.0,0.0,0.0,lx,ly,ls,ctnin,cmax,lccl); 

color(cl); 

polf  (points,  parray), 

/*  bottom  front  of  tank  CW  */ 
parray|0][0]  =  10.0; 
parrayjojjl]  =  0.0; 
parray  |0]  [2  j  =  -5.0; 
parray]  ljjoj  =  15.0; 
parrayjljjlj  =  2.0; 
parray|lj[2]  =  -5.0; 
parray  [2]  (0J  =  15.0; 
parray|2]|l]  =  2.0; 
parray]2]{2]  =  5.0; 
parray  ]S][0]  =  10.0; 
parray|3][l]  =  0.0; 
parrayjsjj2]  =  5.0; 

lightorient(parray,poinU,0.0,0.0,0.0,lx,ly,U,cmin,cmax,ltcl); 

color(cl); 

polf  ( points,  parray )  ; 

/*  bottom  back  of  tank  CW  *  j 
parray|0][0]  =  -10.0; 
parray  jojjlj  =  0.0; 
parray]0)[2]  =  -5.0; 
parray]  1  |(0j  =  -10.0; 
parrayjljjlj  =  0.0; 


parray|l)[2]  =  5.0; 
parrayfcjjoj  =  -15.0; 
parray[2|flj  =  2.0; 

P4fr»y[2j|2i  =  5.0; 
parrayjs][0]  =  -15.0; 
parrayjsjjlj  =  2.0; 
parray(S|(2|  =  -5.0; 

lightorient(parray,  points,  0.0,0.0,0.0,lx,  ly.ls.emin.cmax,  &cl); 
color  (cl);  ' 

polf(points,parray); 

/*  right  side  of  gun  barrel  •/ 
parray[0](0]  =  1.6667; 
parray(Oj(l|  =  8.0; 
parray[ojj2]  =  -0.5; 
parray|l)|0)  =  2.SSSS; 
parray|l)|l)  =  7.0; 
parray[lj|2]  =  -0.5; 
parray|2][0]  =  17.0; 
parray|2](l]  =  7.0; 
parray{2j[2)  =  -0.5; 
parrayisjjo]  =  17.0; 
parray[S)[l]  =  8.0; 
parrayjs]|2|  =  -0.5; 

Ughtorient(parray)points)5.0,2.510.0,lx,ly,b,cmin,cmax,&cl); 

color(cl); 

polf(points,parray); 

/*  top  of  gun  barrel  */ 
parray|0][0)  =  1.8687; 
parrayjoj[l|  =  8.0; 
parray|0|[2|  =  0.5; 
parrayjljjoj  =  1.8887; 
parrayjljjl)  =  8.0; 
parray[l|[2]  =  -0.5; 
parray(2|[0j  =  17.0; 
parray(2||lj  =  8.0; 
paiTay(2j[2j  =  -0.5; 
parrayjsjjoj  =  17.0; 
parrayjsjjlj  =  8.0; 
parray[Sj[2]  =  0.5; 

lightorient(parray , points, 5.0, 2. 5,0.0, lx,ly, Is, cmin,cmax,8ccl); 

color(cl); 

polf(points,parray); 

/*  left  side  of  gun  barrel  */ 
parray(0||0|  =  17.0; 
parrayjojjl]  =  8.0; 
pairay(0](2j  =  0.5; 
parrayjlj|oj  =  17.0; 
parray  [lj  ( 1  j  =  7.0; 
parray(l)(2j  =  0.5; 
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parray|2](0]  =  2.SSSS; 
parray|2]|lj  =  7.0; 
parray[2]|2]  =  0.5; 
parrayjsjjo]  =  1.8887; 
parrayjsjjlj  =  8.0; 
parray|3]|2]  =  0.5; 

Hghtorient(parray, points, 5.0, 2.5, 0.0, lx, ly,l»,eiiuafcinux,ltcl); 

color(ci); 

polf(po  in  ta, parray); 

/*  end  of  gun  barrel  */ 

parray[0||0j  =  17.0; 
p array  jo]  [1]  =  8.0; 
parrayjojj2j  =  -0.5; 
p  array  jlj[0]  =  17.0; 
parray|l](l]  =  7.0; 
parrayjljj2j  =  -0.5; 
parrayjsjjo]  =  17.0; 
parray(2]|lj  =  7.0; 
parrayj2jj2j  =  0.5; 
parrayjsjjo]  =  17.0; 
parrayjsjjlj  =  8.0; 
parrayjS|(2|  =  0.5; 

lightorient(p*rray, points,  50,2.5, 0.0,  lx,  ly.ls.emin.cmax,  ltd); 
color(cl); 

polf(points, parray); 

/‘bottom  of  gun  barrel  */ 
parray(0][0]  =  2.SSS3; 
parrayjojjl]  =  7.0; 
parrayjojj2]  =  0.5; 
parrayjljjoj  =  2.3333; 
parray[l]|lj  =  7.0; 
parrayjljj2j  =  -0.5; 
parrayj2jjoj  =  17.0; 
parrayjsjjlj  =  7.0; 
parrayj2jj2j  =  -0.5; 
parrayjsjjoj  =  17-0; 
parrayjsjjlj  =  7.0; 
parray[3]|2]  =  0.5; 

lightorient(pairay, points, 5.0, 2.5, 0.0, U.ly.U.cmin.cinax.Iccl); 

color(cl); 

polf(points,parray); 

/*  right  side  of  turret  */ 
parray|0]j0]  =  -3.0; 
parrayjojjl]  =  9.0; 
parray|0]]2]  =  -1.0; 
parrayjljjoj  =  -5.0; 
parray  1 1]  [  1  j  =  8.0; 
parray|l][2]  =  -3.0; 

parray  (2jjoj  =  3.0;  * 
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parray|2)|l]  =  6.0; 
parray[2)|2)  =  -3.0; 
parrayjsjjoj  =  1.0; 
p»rr*y[sj(lj  =  9.0; 
p*rr*yjsj|2j  =  -1.0; 

lightorient  (parray  .points,- 1 .0,2.5,0.0,lx,ly ,  ls.cmin  ,cmax,  Jcc  1); 
color(cl); 

po  If  (points, parray ) ; 

/*  front  aide  of  turret  */ 
parray|0]|0]  =  1.6667; 
parrayjojjlj  =  9.0; 
parray(0j(2|  =  -1.0; 
parray(l](0j  =  3.0; 
parrayjljjlj  =  6.0; 
parrayflj(2|  =  -3.0; 
parray  [2  jjoj  =  3.0; 
parray[2|jlj  =  6.0; 
parray(2][2]  =  3.0; 
parrayjsjloj  =  1.6667; 
parray(3]|lj  =  9.0; 
parray(3|(2|  =  1.0; 

ligktorient(parraylpoinUl-1.0,2.5,0.0llxliy,lsleininlcmaxlltcl); 

color(el); 

po  If  ( points,  parray); 

/*  left  side  of  turret  */ 
parray[0)|0j  =  1.6667; 
parray  [0]  1 1]  =  9.0; 
parray  [oj|2]  =  1.0; 
parray  [lj(0]  =  3.0; 
parrayjljjlj  =  6.0; 
parrayjljj2j  =  3.0; 
parTayj2]|0|  =  -5.0; 
parray(2)(lj  =  6.0; 
parray(2][2|  =  3.0; 
parray  [3]  joj  =  -3.0; 
parray|sjjlj  =  9.0; 
parrayjsjj2j  =  1.0; 

liKhtorient(parray  .points,  -1.0, 2.5, 0.0,  lx.ly.b.cmin.cmax^cl); 
color(el); 

polf(points,  parray); 

/*  back  side  of  turret  */ 
parray[0|(0|  =  -3.0; 
parrayjojjlj  =  9.0; 
parray  joj  |2j  =  1.0; 
parrayjljjoj  =  -5.0; 
parrayjljjlj  =  6.0; 
parray  ( lj[2j  =  3.0; 
parray  j2j  joj  =  -5.0; 
parray|2jjlj  =  6.0; 
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pwr»yl»j|aj  =  -3.0; 

PMT»y|Sjjoj  -  -3.0; 
pwr«y|sj|lj  =  9.0; 

PMr»y(Sj(3j  =  -1.0; 

lightorier*  (puirmy, point*, -1.0, 2.5, 0.0, lx,  ly,h,emm,em»*,fccl); 

color(cl);  ' 

po  If  (point*,  p  array ) ; 

/*  top  of  turret  */ 
pMT»y|0)(0j  =  -3.0; 
purrayjojjlj  =  9.0; 
pMT»y|0)(2j  =  1.0; 
p*rr»y(lj(oj  =  -3.0; 
purTeyjljjlj  =  9.0; 
p4rrayjl)[2)  =  -1.0; 

P*rr»y(2](0|  =  1.0; 
p*rr*y(2|(lj  =  9.0; 
parr»y|2j|2]  =  -1.0; 
purreyjsjloj  =  1.0; 
purreyjsjjlj  =  9.0; 
p*ir»y[3|(2j  =  1.0; 

Hghtorient(parr»y, point*, -1.0, 2.5, 0.0, lx, ly,l*lemiii,emax,lEcl); 

color(cl);  ' 

polf(point*,p*rr»y); 

closeobj(); 


} 
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NEAREST  TGT 


{include  "gl.h" 

{include  "fogm.h" 

neureet_tgt(vx,vy,vi1px)py,p*,tgt_idx) 

Coord  vx,  vy,  vs,  px,  py,  pi; 
int  *tgt_idx; 

{ 

flout  dist,  dist_to_los(); 
flout  min_dist; 
flout  numtgts; 

extern  flout  tgt  _poejMAX_TGTS)|3); 
int  index; 

numtgts  =  10; 

min_dist  =  dist_to_k>e(vx,vy,vslpxlpylpsllctgt_poe[0]|0]); 
*tgt_idx  =  0; 

for  (index  =  1;  index  <  num_tgts;  ++index)  { 

dist  =  distto  jos(vx,vy,vs,px,py,ps,&tgt_pos[indexj(0]); 
if  (dist  <  mindist)  { 
mindist  =  dist; 

‘tgtidx  =  index; 

} 

} 

} 
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NPOLY  ORIENT 


/*  npolyjorient.c  */ 

{include  <gl.h> 

{include  <math.h> 

int  npoly_orient(ncoord»,xy*,xin»ide,yiB«de,*in»ide) 
unsigned  int  ncoords; 

Coord  xys[)[3j; 

Coord  xinside,  yinside,  sinside; 

{ 


register  unsigned  short  int  ij;  /*  loop  temps  */ 

Coord  center[S|;  /*  center  coordinate  of  the  polygon  */ 

Coord  a(3j,  b[3);  /*  vector  hold  locations  for  the  vectors  that  run 
from  the  center  coordinate  to  the  points  of  the 
polygon  */ 

Coord  xn(3],  xmn(3j;  /*  points  on  line  containing  normal  that  are 
on  opposite  sides  of  the  plane  containing 
the  polygon. 

7 

float  distton;  /*  distance  to  point  n  from  pt  inside.  */ 
float  disttomn;  /*  distance  to  point  -n  from  pt  inside.  */ 
Coord  normal[3|;  /*  the  normal  vector  computed  from  a  x  b  */ 


/*  compute  the  center  coordinate  of  the  polygon  */ 
centerjO]  =  0.0; 
centerjlj  =  0.0; 
center(2|  =  0.0; 

for(i=0;  i  <  ncoords;  i++) 

{ 

for(j=0;  j  <  3;  j++) 

{ 

centerlj)  +=  xys|i]|j]; 

} 

} 

/*  divide  out  by  the  number  of  coordinates  */ 
for(j=0;  j  <  3;  j++) 

{ 

eenter[j]  =  center  [j]/ (float)  ncoords; 

} 
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/*  check  the  first  2  coordinates  of  the  polygon  for  their  direction  */ 

/*  compute  vector  a.  It  runs  from  the  center  coordinate  to  coordinate  0  */ 
for(j=0;  j  <  2;  j44) 

{ 

»lj]  =  xys|0]lij  -  center  [j]; 

} 

/*  compute  vector  b.  It  runs  from  the  center  coordinate  to  coordinate  1  */ 
for(j=0;  j  <2;  j++) 

{ 

bill  =  *y»U)li|  *  centerjj); 

} 

/*  compute  a  x  b  to  get  the  normal  vector  */ 
normal[0)  =  a|l]*b|2]  -  a|2]*b[l|; 
normal[ l]  =  a[2]*b[0]  •  ajoj*b(2]; 
normal[2j  =  a[oj*bjl]  -  ajlj*bjoj; 

/*  compute  point  n,  offset  pt  from  center  in  direction  of  normal  */ 
for(j=0;  j  <  2;j44) 

{ 

xn[j)  =  center[jj  4  normal  [jj; 

} 

/*  compute  point  -n,  offset  pt  from  center  in  opposite  direction 
from  normal. 

V 

for(j=0;  j  <  2;  j++) 

{ 

xmn[jj  =  centerjj]  -  normal^); 

} 

/*  compute  the  distance  the  inside  pt  is  from  point  n  */ 
distton  =  sqrt((xn|Oj  •  xinside)  *  (xn|0]  •  xinside)  4 
(xn[l|  -  yinside)  *  (xn|l|  -  yinside)  4 
(xn(2]  •  sinside)  *  (xn|2|  •  sinside)); 

/*  compute  the  distance  the  inside  pt  is  from  point  -n  */ 
disttomn  =  sqrt((xmn|0]  -  xinside)  *  (xmnjOj  -  xinside)  4 
(xmn|lj  •  yinside)  *  (xmn|lj  *  yinside)  4 
(xmn|2]  •  sinside)  *  (xmn(2|  *  sinside)); 
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/*  if  (he  dist(n)  <  diat(-ii),  (hen  ■  points  back  towards  (he 
inside  point  ud  is  on  (he  same  side  of  the  plane  as  inside, 
axbii  (hen  clockwise. 

.  7 

iffdistton  <  disttomn) 

{ 

retnrn(l);  /*  clockwise  */ 

} 

else 

{ 

return  (0);  /*  counterclockwise  */ 

} 


} 


aid 


PRELAUNCH 


/•  The  function  prelaunch  is  the  uaer  interface  portion  of  the  FOG-M 
flight  simulation.  It  allows  the  operator  to  interactively  enter 
critical  data  items  necessary  to  simulate  the  missile  in  flight. 

The  function  returns  the  initial  launch  position  in  the  x-s  plane 
and  also  the  direction  of  flight.  */ 


f  include  "gl.h" 

# include  "device. h" 

#  include  "fogm.h" 

^include  "math.h" 

prelaunch(vx,  vy,  vs,  direction,  compassdir,* active,  obj,  tag) 

Coord  *vx,  *vy,  *vs; 
double  *direction; 
float  ‘compassdir; 
int  ‘active; 

Object  obj[7|; 

Tag  tag[6|; 

{ 

float  gnd_level(); 
float  compass(); 

int  screencnt,  launchlock,  targetloch; 

int  xval,  yval,  xlaunch,  ylaunch,  xtarget,  ytarget,  utm_x,  utm _y; 
char  xtemp|35],  ytemp[S5],  dist[3S],  heading[35j; 
float  distance; 

double  xdistance,  ydistance; 

Colorindex  unmask; 

xtemp|0|  =  ’ 
ytempjoj  =  »  ’; 
dist[0]  =  ’  ’; 
heading  |0)  =  ’  ’; 

unmask=(l<<getplanes())  -1; 

writemask(unmask); 

if  (TV)  viewport^, «S5, 0,474); 

else  viewp©rt(0, 1023, 0,767); 

pushmatrix(); 

ortho}  (0.0, 1033.0,0.0,7(17.0) ; 

‘direction  =  0.0;  /*  initialise  the  direction  ‘/ 

cursoff();  /*  turn  the  cursor  off  */ 

calk>bj(obj|SCREENl]);  /*  display  Kreen  1  */ 

swapbuffers(); 


scrcencnt  =  I; 


/*  initialise  counter  for  screen  displsys  */ 


whik(TRUE)  { 

frontbuflfer(TRUE) ; 

if  (getbutton(MOUSE2)  kk  !(getbutton(MOUSEl))  kb  !(getbutton(M0USE2)))  { 
ringbell(); 

while  (getbutton(MOUSE2)); 
screencnt  +=  1; 

if  (screencnt  ==  2)  cnllobj(obj|SCREEN2j); 
else  if  (screencnt  ==  S)  c*Uobj(obj[SCREEN3]); 
else  break; 

} 

if  (getbntton(MOUSEl)  kk  (getbutton(MOUSE2))  kk  (getbntton(MOUSES)))  { 
*sctive  -  FALSE; 
goto  exit; 

} 

} 

froijtbuffer(FALSE); 

editobj(objjFLTPATHj);  /*  ersse  previous  missile  path  */ 

objreplace(  t  ag  [MISSILE] ) ; 

circf(0.0,  0.0,  0.0); 

move2(0.0,  0.0); 

draw2(0.0,  0.0); 

objreplace(tag[TGT]); 

circf(0.0,  0.0,  0.0); 

closeobj(); 

editobj(obj[STATS|);  /*  ersse  previous  Isunch  statistics  */ 

objreplsce(tagjHEADj); 

charstr(""); 

cmov2i(115,00); 

chsrstr(""); 

objreplace(tag[TARGET]); 

ehar*tr(""j; 

cmov2i(0,0); 

charstr(""); 

closeobj(); 

setcursor(0,RED,unmssk);  /*  set  up  cursor  and  mouse  */ 

attachcursor(MOUSEX,  MOUSEY); 

setvaluator(MOUSEX, 284, 0,707); 

setvaluator(MOUSEY, 284, 0,707); 

cnrson(); 

launch  lock  =  FALSE; 
targetlock  =  FALSE; 

callobj(obj|CONTOUR|);  /*  load  static  displays  into  both  buffers  */ 
eaIk>bj(obj|INSTR|); 

callobj(obj[STATSJ);  /*  included  so  swapped  buffer  doesn’t  have  "hole”  */ 

•wapbuffersQ; 
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callobj{obj|CONTOUR|); 
eallobj  (obj  jlNSTR] ) ; 


while(TRUE)  { 

if  (getbutton(MOUSEl)  kb  (getbutton(MOUSE2))  kb  (|etbakton(MOUSES)))  { 

*  active  =  FALSE; 
goto  exit; 

} 

xv el  =  getvaluator(MOUSEX);  /*  reed  the  x  and  y  moose  position*  */ 

yval  =  getvaluator(MOUSEY); 

utm_x  =  (50000  +  (int)(xval  *  GRID  F ACTOR));  /•  compote  grid  coordinates  */ 

utm_y  =  (80000  +  (int)(yval  *  GRID_FACTOR)); 

*printf(xtemp,"%4d",otm_x);  */*  store  coordinates  in  temporary  buffer  */ 

•printf(ytemp,"%4d",utm_y); 

/*  if  LEFT  MOUSE  selected  lock  in  launch  position  and  update  control  panel  */ 

if  (getbutton(MOUSES)  kb  (!getbutton(MOUSE2))  kb  (!getbutton(MOUSEl)))  { 
ringbeilQ; 
xlaunch  =  xval; 
ylaunch  =  yval; 
launchlock  =  TRUE; 

*vx  =  ((float)((xval  *  FT_10K)/767)); 

•vs  =  -((float)((yval  *  FT_10K)/767)); 

•vy  =  gnd_level(*vx,  *vs)  +  200.0; 

editobj(obj|ST  ATS]); 

objrepl*ce(tag  [LAUNCH]); 

clbarstr(xtemp); 

cmov3i( 170,220); 

charstr(ytemp); 

closeobjQ; 

)  /•  end  of  MOUSES  hit  •/ 

/*  As  long  as  LEFT  MOUSE  not  selected,  keep  on  displaying  current  UTM 
grid  coordinates  in  control  panel  area.  */ 

if  (llaunchlock)  { 

editobj(obj|STATS|); 

objreplace(tag[LAUNCH]); 

charstr(xtemp); 

cmov2i(170,220); 

charstr(ytemp); 

closeobj(); 


/*  if  RIGHT  MOUSE  selected  lock  in  target  and  update  control  panel.  */ 

if  (getbutton(MOUSEl)  kb  (!getbutton(MOUSES))  bk  (!getbutton(MOUSE2)))  { 
ringbeilQ; 
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xtarget  =  xval; 

ytarget  =  yval; 

targetlock  =  TRUE; 

editobj  (obj  |  ST  ATS] ) ; 

objreplace(tag[TARGETj); 

charstr(xtemp); 

cmov2i(170,140); 

charstr(ytemp); 

cloeeobjQ; 

} 

/*  As  long  as  RIGHT  MOUSE  not  selected  keep  on  displaying  current  UTM 
grid  coordinates  in  control  panel  area.  */ 

if  (Itargetlock)  { 

if  (launchlock)  { 

xdistance  =  ((double) (xval  -  xlaunch)); 
ydistance  =  ((double)(yval  •  ylaunch)); 

distance  =  sqrt((float) (xdistance  *  xdistance  +  ydistance  *  ydistance)); 
distance  =  distance  *  GRID  FACTOR; 
sprintf(dist,"%5.0f  METERS",  distance); 

‘direction  =  atan2 (ydistance,  xdistance); 
if  (‘direction  <  0.0)  ‘direction  +=  TWOPI; 

‘compassdir  =  compass(‘direction); 

sprintf(heading,n%d  DEGREES",  (int)*compassdir); 

editobj(obj)STATSj); 

objreplace(tag[TARGET]); 

charstr(xtemp); 

cmov2i(170,140); 

charstr(ytemp); 

objreplace(tag[HEAD]); 

charstr(heading) ; 

cmov2i(  115,00); 

charstr(dist); 

doseobjQ; 

} 

} 

/*  if  launch  position  and  target  location  have  been  selected  by  the 

operator  compute  the  direction  of  the  missile  and  distance  to  target.  */ 

if  (launchlock  &&  targetlock)  { 

xdistance  =  ((double) (xtarget  -  xlaunch)); 
ydistance  =  ((double)(ytarget  -  ylaunch)); 
distance  =  sqrt((float) ((xdistance  *  xdistance)  + 

(ydistance  *  ydistance))); 
distance  =  distance  *  GRID  FACTOR; 
sprintf(dist,"%5.0f  METERS",  distance); 

‘direction  =  atan2(ydistance,  xdistance); 
if  (‘direction  <  0.0)  ‘direction  +=  TWOPI; 

‘compassdir  =  compass(*directioa); 


writemaak  (S  A  VEM  AP) ; 
callobj  (obj  (FLTP  ATH] ) ; 
writemaak  (unmuk ) ; 
callobj(obj[STATS]); 
swapbuffersQ; 

} 

exit: 

curaoffQ; 

popmatrix(); 

} 


RANDNUM 


/*  randnum.c  -  returns  a  random  float  between  sero  and  one  * / 

static  long  seed  =  1234567; 

rand  seed  ( newseed ) 
long  newseed; 

{ 

seed  =  newseed; 

} 


float  randnumQ 

{ 

long  multQ; 

seed  =  (mult (seed, 314 15821)  +  1)  %  100000000; 
return(seed  /  100000000.0); 

} 

long  mult(p,q) 
long  p,q; 

{ 

long  p0,  pi,  qO,  ql; 

pi  =  p  /  10000; 
pO  =  p  %  10000; 
ql  =  q  /  10000; 
q0  =  q  %  10000; 

return((((p0*ql  +  pl*q0)  %  10000)  *  10000  +  p0*q0)  %  100000000); 

} 
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READCONTROLS 


/*  reads  the  values  from  the  operator’s  controls  (mouse  and  dials)  */ 

#  include  "gl.h"  /*  graphics  lib  defs  •/ 

#include  "fogm.h"  /*  fogm  constants  */ 

^include  "device. h"  /*  device  definitions  */ 

read_controls(designate,  greyscale,  flying,  active,  speed,  direction, 
compassdir,  alt,  pan,  tilt,  fovy) 

int  "designate,  "greyscale,  "flying,  "active,  "fovy; 
float  "speed,  "compassdir; 
double  "direction,  "pan,  "tilt; 

Coord  "alt; 

{ 

extern  float  randx,  randy,  rands; 
float  randnumQ; 

Colorindex  colors) I]; 

/*  quit  if  all  three  mouse  buttons  are  pushed  "/ 

if)getbutton(MOUSEl)  bb  getbutton(MOUSE2)  bb  getbutton(MOUSES))  { 

•flying  =  FALSE, 

"active  =  FALSE; 

} 

else  { 

if  ( getbutton (MOUSES )  bb  !(getbutton(MOUSE2)))  (  /*  Zoom  In  "/ 

"fovy  =  ("fovy  <  (80  +  DELTAFOVY))  ?  80  :  "fovy  .  DELTAFOVY; 

} 

if  (getbutton(MOUSEl)  bb  !(getbutton(MOUSE2)))  {  /*  Zoom  Out  */ 

"fovy  =  ("fovy  >  (550  -  DELTAFOVY))  ?  550  :  "fovy  +  DELTAFOVY; 

} 

if  (getbutton(MOUSES))  {  /*  designate/reject  target  */ 

if  ("designate)  {  /*  see  if  target  in  sights  */ 

/*pushmatrix(); 

pushviewport(); 

pushattributesQ; 

viewport(0,  1028,  0,  787); 

ortho2(0.0,  1028.0,  0.0,  767.0); 

cmov2s((Scoord)(768/2),  (Scoord) (768/2)); 

readpixels(  1  .colors) ; 

if  ((colors{0)  >=  MIN  TGT  COLOR)  bb  (colors)O)  <=  MAX  TGT_COLOR))  ("/ 
"designate  =  FALSE; 
ringbellQ; 

randx  =  80.0  *  randnum()  -  15.0; 
randy  =  10.0  *  randnumQ  -  5.0; 
rands  =  10.0  *  randnumQ; 
while  (getbutton(MOUSE2)); 


popattributes(); 
popvicwport(); 
popmatrixQ;  ‘/ 

} 

«l>e  {  /*  reject  currently  designated  target  */ 

ringbell(); 

‘designate  =  TRUE; 

/*  re-adjust  tilt  and  pan  values  appropriately  */  ; 

} 

} 

if  (‘greyscale  getvaluator(DlALS))  {  /*  DIALS  indicates  color  change  */ 
‘greyscale  =  !*  greyscale; 
setvaluator  ( DIALS, *  grey  sc  ale, 0, 1 ) ; 
colorramp(  *  greyscale,  F  ALSE) ; 

} 

‘speed  =  (float) (getvaluator(DIAL2)  /  SPEEDSENS);  /*  get  desired  speed  */ 
‘alt  =  (Coord)(getvaluator(DIAL4)); 

‘pan  =  DTOR  *  (double)  (-getvaluator(MOUSEX))  /  PANSENS; 

•tilt  =  DTOR  *  (double)  (getvaluator(MOUSEY))  /  TELTSENS; 

‘compassdir  =  (float)getvaluator(DIALO)  /  DIRSENS; 

/*  keep  ‘direction  between  0  and  S60,  update  valuator  if  changed  */ 
if  (‘compassdir  >=  360.0)  { 

‘compassdir  -=  360.0; 

setvaluator(DIALO,(int)(*compassdir‘DIRSENS),  (int)(-S60*DIRSENS), 
(int)(720*DIRSENS)); 

} 

if  (‘compassdir  <  0.0)  { 

‘compassdir  +=  360.0; 

setvaluator(DIALO,(int)(*compaasdir‘DIRSENS),  (int)(-S60*DIRSENS), 
(int)  (720*  DIRSENS)) ; 

} 

/‘convert  ‘direction  from  compass  degrees  to  trigonometric  radians  */ 
‘direction  =  (‘compassdir  <=  90.0)  ?  DTOR  *  (90.0  -  ‘compassdir)  : 

DTOR  *  (450.0  •  ‘compassdir); 

} 

} 
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ROAD  BOUNDS 


{  include  "math.h" 

{include  "fogm.h" 

{define  X  0 
{define  Y  I 
{define  Z  2 

{define  NONE  0 

roed_bounds(ptl,  pt2,  ptS,  roadwidth,  left_ptl,  rightptl,  left_pt2, 
rightpt2,  fir* t_x  grid,  firstigrid,  laitxgrid,  last*  grid) 

float  ptl|3|,  pt2|3],  ptS|3),  road_width; 

float  left_ptl|3],  right_ptl[3],  left_pt2|S|,  right_pt2[Sj; 

int  *first_xgrid,  *la»t_xgrid,  *firat  lgrid,  *laat_>grid; 

{ 

float  deltax,  delta  s,  aegjdir,  min  x,  maxjc,  min  s,  max  i; 
float  left_endl[3],  right_endl[3],  left_start2[3j,  right_atart2|3{, 
left_end2|3],  right_end2|3|; 
int  intersection  type; 

/*  determine  the  corner  points  of  the  segment  */ 

delta_x  =  pt2(X]  *  ptl[X); 

delta  s  =  pt2[Z]  -  ptljZj; 

seg  dir  =  atan2(delta  s,  delta  x); 

left  endljX]  =  pt2[Xj  4  (eos(sig  dir  4  HALFPI)*road_width/2.0); 
right_endl[Xj  =  pt2|X]  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
leftendl[Z]  =  pt2[Z]  4  (sin(seg_dir  4  HALFPI)*road_width/2.0); 
right_endl|Z]  =  pt2[Z]  4  (sin(seg  jdir  -  HALFPI)*road_width/2.0); 

if  ((pt2(X|  !=  Pt3|X])  ||  (pt2|Z]  !=  pt3[Z]))  { 

/*  we  are  not  working  with  the  final  segment  of  this  road,  find 
the  intersection  of  this  segment  with  the  next  one  */ 
delta  x  =  pt3(X]  •  pt2[X|; 
delta_s  =  pt3|Z|  -  pt2|Z|; 
seg_dir  =  atan2(delta_s,  delta_x); 

left_»tart2[X]  =  pt2[X]  +  (cos(seg_dir  4  HALFPI)*road_width/2.0); 
right _start2|X|  =  pt2|X]  4  (eos(seg_dir  -  HALFPI)*road_width/2.0) 
left_start2[Z]  =  pt2|Z]  4  (sin(seg_dir  4  HALFPI)*road_width/2.0); 
right_start2(Z]  =  pt2(Zj  4  (sin(seg  dir  •  HALFPI)*road_width/2.0); 
lefl_end2|X]  =  pt3|X]  4  (cos(seg_dir  4  HALFPI)*road_width/2.0); 
right_end2(X]  =  ptS[X]  4  (coe(seg_dir  -  HALFPI)*road_width/2.0); 
left  end2|Z]  =  ptSjZ]  4  (sin(seg_dir  4  HALFPI)*road_width/2.0); 
right_end2[Zj  =  pt3|Z]  4  (sin(seg  dir  -  HALFPI)*road_width/2.0); 

/*  find  the  intersection  point  of  the  left  hand  sides  of  the 
first  and  second  road  segments  */ 
line_intersect2(left_ptl,  left  endl,  left_start2,  left_end2, 
left  j>t2,  Aintersection_type); 


if  (intersection  type  ==  NONE)  { 
left  j*2(X]  =  left  endl[X]; 
left  _pt2(Zj  =  left  VndljZj; 

) 

/*  Sad  the  intersection- point  of  the  right  head  (idea  of  the 
first  and  second  road  segments  */ 
liae_iatersect2(right_ptl,  right _endl,  right_start2,  right_end2, 
right _pt2,  irinter»ection_type); 
if  (intersection  type  =  =  NONE)  { 
right_pt2(X|  =  right_endl(X]; 
right_pt2[Z|  =  right_eadl|Z); 

) 

} 

else  { 

/*  this  is  the  final  segment  of  this  road  •/ 
left_pt2|X]  =  left_endi|X); 
left_pt2|Z)  =  left  endl|Z]; 
right_pt2|X]  =  right_cndl|Xj; 
right_pt2|Z]  =  right  _endl[Z|; 

} 

/*  determine  the  min  and  max  x  and  s  valves  */ 

minx  =  left  _ptl[X); 

mux  =  leftptljX]; 

mins  =  left  _pt  1  ( Z  ] ; 

mui  =  leftpt  1  >Z] ; 

if  (right_ptl|X|  <  min  x)  min  x  =  rightjptl|X); 
if  (right  _j>tl[X)  >  max_x)  max_x  =  right_ptl[X); 
if  (right  j>tl|Z]  <  min  s)  min_t  =  right_ptl[Z); 
if  (rightptljzj  >  max  i)  max  i  =  right  j>tl[Z|; 
if  (left_pt2[X|  <  min  x)  min  x  =  left_pt2[Xj; 
if  (left_pt2|X)  >  mu  x)  max  x  =  left_pt2(X|; 
if  (left_pt2(Z]  <  min  i)  min  i  =  left  jpt2(Zj; 
if  (leftpt2[Z]  >  max  i)  max  i  =  left_pt2(Z|; 
if  (right_pt2(X)  <  min  x)  min_x  =  right  pt2)Xj; 
if  (right_pt2|X|  >  mu  x)  mu  x  =  right _pt2[Xj; 
if  (right_pt2jZ|  <  min  i)  min_i  =  right_pt2[Z); 
if  (right_pt2|Z|  >  max  i)  max  i  =  right  pt2[Zj; 

*  first  xgrid  =  (int)(min_x/FT_100M); 

‘first!  grid  =  (int)(min_«/FT_100M); 

‘lastxgrid  =  (int)(max_x/FT_100M); 

*last_igrid  =  (iat)(max_i/FT_100M); 
if  (‘first  jc grid  <  0)  ‘first  xgrid  =  0; 
if  (‘firstigrid  <  0)  ‘first* grid  =  0; 
if  (‘last  xgrid  >  98)  ‘last  xgrid  =  98; 
if  (‘lastigrid  >  98)  ‘lastigrid  =  98; 


SORT  ARRAY 


•ort  array  (array,  nnmjentriea,  dec  ending,  teetindex) 
float  array [10][S]; 

int  num  entriee,  decending,  te*tmdex; 

{ 

int  i  j; 

float  temp[S]; 

for  (i  =  0;  i  <  numentriea;  +  +i)  { 

for  (j  =  i  +  1;  j  <=  nnmjentriea;  ++j)  { 

if  (((decending)  kk  (array[j)|test_index)  >  array |i|| test _index|))  || 

((.'decending)  kk  (array [j][te»t_index|  <  array  |ij[teat_indexj)))  { 
tempjOj  =  array[i||0];* 
tempj  1  j  =  array[ij|l|; 
tempjflj  =  array|ij(2j; 
array  [i]|0]  =  array[j]|0]; 
arrayjijjl]  =  array(ji[lU 
arrayji]|2]  =  arraylijjflj; 
array(j||°]  =  temp(0|; 
airayjjjj  lj  =  tempjlj; 
arTay[j]|2)  =  temp|2); 

} 

} 

} 

)  '*> 
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UP  LOOK  POS 


/*  compute  the  cun  era’s  look  at  position  */ 

# include  "fogm.h"  /*  fofm  constant*  */ 
f  include  "math.h"  /*  math  routine  definitions  */ 

#  include  "gl.h"  /*  graphics  definitions  */ 

updatelook  _posit  (direct  ion,  pan,  tilt,  vx,  vy,  vs, 
tgtx,  tgty,  tgts,  designate,  px,  py,  ps) 

double  direction,  pan,  tilt; 

Coord  vx,  vy,  vs,  tgtx,  tgty,  tgts,  *px,  *py,  *ps; 
int  designate; 

{ 

extern  int  frameent; 
double  lookdir; 

if  (designate)  {  /*  missile  is  not  locked  on  to  a  target  */ 

/*  compute  direction  camera  is  looking  */ 
lookdir  =  direction  +  pan; 

/*  compute  a  coordinate  along  camera's  line  of  sight  */ 
*px  =  vx  +  cos(lookdir)  *  MAXLOOKDIST; 

*ps  =  vs  -  sin(lookdir)  *  MAXLOOKDIST; 

if  (frameent  <  15)  ( 

•py  =  4.0  *  vy  *  (14  -  frameent)  /  14.0; 
framecnt++; 

} 

else  { 

*py  =  vy  +  MAXLOOKDIST  *  tan(tUt); 

} 

} 

else  { 

•px  =  tgtx; 

•py  =  tgty; 

•ps  =  tgts; 

} 


} 


as* 


UP  MSI#  POSIT 


tv» 


» .-I 


/*  Compote  new  miaeile  poeition  "/ 

f  include  "gl.h"  /*  graphics  definitions  */ 

findide  "device. h"  /"  graphics  device  definitions  */ 

#  include  "fogm.h"  /*  fogm  constants  */ 

f  include  "math.h"  /*  math  function  declarations  "/ 

f  include  <sya/types.h>  /*  contains  the  time  sturcture  tms  */ 

# include  <sys/times.h>  /*  for  time  calk  */ 

updatemissilepoeit  (direction,  compassdir,  speed,  designate, 
tgtx,  tgty,  tgts,  vx,  vy,  vs,  flying) 

double  "direction; 
float  "compassdir; 
float  speed; 
int  designate; 

Coord  tgtx,  tgty,  tgts; 
int  "flying; 

Coord  "vx,  "vy,  "vs; 


static  long  seconds; 

static  long  lastsec  =  -999;  /*  -999  is  flag  to  indicate  no  value  */ 

struct  tms  times truct; 

float  deltadist,  gndlevel,  gnd_level(),  compassQ,  ht  above  tank; 
long  float  deltax,  deltas,  disttotank; 

seconds  =  times  (Id  times  truct); 

/*  compute  distance  missile  must  move  ahead  to  maintain  speed  */ 
if  (lastsec  ==-999) 
deltadist  =  0.0; 

else 

deltadist  =  (speed /FPS_TO_KTS)" (seconds  -  lastsec); 

lastsec  =  seconds;  /*  save  for  next  pass  */ 
if  (designate)  (  /*  missile  under  operator  contol,  not  locked  on  tgt  */ 
"vx  +=  deltadist  *  cos(*directioa); 

"vs  •=  deltadkt  *  sin( "direction); 

/*  keep  missile  at  least  50  ft  above  ground  level  */ 

gndlevel  =  gnd_level(*vx,  *vs); 

if  ("vy  <  (gndlevel  +  50.0))  "vy  =  gndlevel  +  50.0; 


} 

eke  ( 


deltax  =  "vx  -  tgtx; 

deltas  =  "vs  -  tgts; 

dist  to  tank  =  hypot(deltax,  deltas); 


v.  v  v  r 


if  (deltadiat  >  (float  )diat_to_tank)  {  /'  hit  on  target  */ 

deltadiat  =  (float  )diat_to_tank  -  5.0; 

'flying  =  FALSE; 

laataec  =  -999;  /*  no  value  flag  for  next  launch  */ 

} 

'direction  =  (double)atan2((float)deltaa,  ( float )-delt ax); 
if  ('direction  <  0.0)  'direction  +=  TWOPI; 

'compaasdir  =  compaaa('direction); 

setvaluator(DIALO,(int)(*compaaedir*DIRSENS),  (int)(-S00'DIRSENS), 
(ini)  (720*  DIRSENS)) ; 


*vx  +=  (deltadiat  *  cos( 'direction)); 

*vi  -=  (deltadiat  *  ain('directioh)); 
htabovetank  =  (float)'vy  -  gnd_level(tgtx,tgts); 

*vy  -=  (Coord)((ht_above_tank  *  deltadiat)  /  (float )diat_to_tank); 

> 

} 
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VIEW  BOUNDS 


^include  "fogm.h" 

#  include  "gl.h" 
f  include  "math.hh 

view_bounds(vx,  vy,  v*,  px,  py,  pt,  tilt,  fovy, 
fintxgrid,  fin 1 1 grid,  lutxgrid,  lutsgrid) 

Coord  vx,vy,v»; 
doable  tilt; 
int  fovy; 

■beat  'fintxgrid,  'fintsgrid,  'lutxgrid,  'lutigrid; 

{ 

float  ix,  it;  /*  the  intersection  points  */ 
float  lookdir; 

float  deltax,  deltay,  deltas,  deltajalt,  fx,  fy,  ft; 

float  halffovy; 

float  lower  edge  angle; 

/*  compute  the  direction  the  camera  is  looking  */ 
lookdir  =  ntan2((float)(vs  -  ps),  (float)(-(vx*px))); 
if  (lookdir  <  0.0)  lookdir  +=  TWOPI; 

if  (vy  >  py)  ( 

/*  tilt  angle  is  negative  */ 
deltax  =  px  *  vx; 
deltay  =  py  -  vy; 
deltas  =  pi  -  vs; 

delta  alt  =  pow((floot)MlN,  ALTSCALE)  -  vy; 

} 

else  { 

/*  tilt  angle  is  positive,  use  the  lower  fustrum  edge  instead 
of  the  line  of  sight  to  compute  the  view  bounds  */ 

/*  compute  a  coordinate  along  the  lower  fustrum  edge  */ 

half  fovy  =  ((float  )fovy/20.0*DTOR); 

lower  edge  angle  =  tilt  -  half  fovy; 

fx  =  vx  +  co#(lookdir)*MAXLOOKDIST; 

fs  =  VI  -  sin  (lookdir)  'MAXLOOKD1ST ; 

fy  =  vy  +  tan(lower_edge_angle)*MAXLOOKDIST; 

deltax  =  fx  -  vx; 

deltay  =  fy  -  vy; 

deltas  =  fs  -  vs; 

delta  alt  =  pow(( float) MIN,  ALTSCALE)  -  vy; 

) 

ix  =  vx  +  ((deltax/dehay)*delta_alt); 
is  =  vs  +  ((deltu/deltay)*delta_alt); 


/*  compute  which  grid  objects  should  be  sent  through  the  geometry 
pipeline  */ 

231 


if  (deltay  >  0.0)  { 

/*  the  fustrum  i>  looking  totally  skyward,  doa’t  bother  doing 
any  terrain  */ 

*  firs  tx  grid  =  0; 

*  firsts  grid  =  0;  { 

Mastxgrid  =  0; 

*  lasts  grid  =  0; 

} 

else  { 

/*  display  20  grid  squares  on  all  sides  of  the  intersection  point  */ 

*  firs tx grid  =  (int)(ix/FT_100M)  -  20; 

Mastxgrid  =  (int)(ix/FT_100M)  +  20; 

*firstsgrid  =  (int)(-is/FT_100M)  -  20; 

Mastsgrid  =  (int)(-is/FT_100M)  +  20; 

/*  insure  that  objects  drawn  include  the  current  missile  position  */ 
if  ((int)(vx/FT_100M)  <  *firstxgrid) 

‘firstxgrid  =  (int)(vx/FT_100M); 
if  ((int)(vx/FT_100M)  >  *lastxgrid) 

*lastxgrid  =  (int)(vx/FT_100M); 
if  ((int)(-vs/FT_100M)  <  *firstsgrid) 

*  first sgrid  =  (int)(-vs/FT_100M); 
if  ((int)(-vs/FT_100M)  >  Mastsgrid) 

‘last  sgrid  =  (int)(-vs/FT_100M); 
if  (‘firstsgrid  <  0)  ‘first sgrid  =  0; 
if  (‘firstxgrid  <  0)  ‘firstxgrid  =  0; 
if  (Mastsgrid  >  98)  Mastsgrid  =  98; 
if  (Mastxgrid  >  98)  Mastxgrid  =  98; 

} 

} 


332 


LIST  OF  REFERENCES 


1.  PC  Connection  advertisement,  PC  Magazine,  v.  6,  no.  11,  p.  241,  June  9, 
1987. 

2.  Orlansky,  J.  and  String,  J.,  "Reaping  the  Benefits  of  Flight  Simulation,"  in 
Computer  Image  Generation,  edited  by  B.  Schachter,  John  Wiley  Sc  Sons, 
Inc.,  New  York,  New  York,  1983. 

3.  US  Army  Combat  Developments  Experimentation  Center  (USACDEC) 
Technical  Report,  Computer  Graphics  Fiber  Opties  Guided  Missile  Flight 
Simulator  (FOG-M  Simulator j  Required  Instrumentation  Capability  (RIC), 
Fort  Ord,  California,  1986. 

4.  Mar,  Roland  K.,  "FOG-M:  Another  Army  Orphan  for  the  Marines?"  U.  S. 
Naval  Institute  Proceedings,  v.  113/6/1012,  pp.  95-97,  June  1987. 

5.  Kotas,  Jim,  "Computer  Image  Generation:  Realistic  Simulation,"  National 
Defense,  v.  70,  no.  412,  pp.  26-31,  November  1985. 

6.  Berthiaume,  Richard,  Karnavas,  Gary,  and  Bernsteen,  Stan,  "Graphical 
Representations  of  DMA  Digital  Terrain  Data  on  Low  Cost  Commercial 
Graphics  Workstation,"  Proceedings  of  the  IEEE  1086  National  Aerospace 
and  Electronics  Conference,  v.  3,  pp.  992-996,  1986. 

7.  Silicon  Graphics,  Inc.,  IRIS  User’s  Guide,  Mountain  View,  California,  1986. 

8.  Fox,  Teresa  A.,  Clark,  Philip  D.,  "Development  of  Computer-generated 
Imagery  for  a  Low-cost  Real-time  Terrain  Imaging  System,"  Proceedings  of 
the  IEEE  1986  National  Aerospace  and  Electronics  Conference,  v.  3,  pp. 
986-991,  1986. 

9.  Defense  Mapping  Agency,  Product  Specifications  for  Digital  Landmass 
System  (DLMS)  Data  Base,  2d  ed.,  April  1983. 

10.  US  Army  Combat  Developments  Experimentation  Center  (USACDEC) 
Technical  Report,  Fort  Hunter  Liggett  Digital  Terrain  Database  on  the  VAX 
Computer,  Fort  Ord,  California,  1985. 


23S 


11.  Hearn,  Donald,  and  Baker,  M.  Pauline,  Computer  Graphic*,  Prentice-Hall, 
Inc.,  Englewood  Clifls,  New  Jersey,  1986. 

12.  McGrew,  J.  F.,  "Exaggerated  Vertical  Scale  in  CGI  Terrain  Perspectives," 
Proceeding t  of  the  Human  Factor*  Society  27th  Annual  Meeting,  ▼.  1,  pp. 
33-35,  1983. 

13  Fuchs,  Henry,  Abram,  Gregory  D.,  and  Grant,  Eric  D.,  "Near  Real-Time 
Shaded  Display  of  Rigid  Objects,"  Computer  Graphic*,  ▼.  17,  no.  3,  pp.  65- 
72,  July  1983. 

14.  Sedgewick,  Robert,  Algorithm*,  Addison-Wesley  Publishing  Co.,  Reading, 
Massachusetts,  1983. 


Distribution  List 


Defense  Technical  Information  Center 
Cameron  Station 

Alexandria,  VA  22314  2  copies 

Library,  Code  0142 
Naval  Postgraduate  School 

Monterey,  CA  03943  2  copies 

Center  for  Naval  Analyses 
2000  N.  Beauregard  Street 

Alexandria,  VA  22311  1  copy 

Director  of  Research  Administration 
Code  012 

Naval  Postgraduate  School 

Monterey,  CA  93043  1  copy 

* 

Roger  Casey 

Naval  Ocean  Systems  Center 
Code  854 

San  Diego,  CA  92152  1  copy 

Mr.  Russell  Davis 
HQ,  USACDEC 
Attention:  ATEC-IM 

Fort  Ord,  CA  93941  1  copy 

Prof.  Michael  Zyda 
Code  52Zk 

Naval  Postgraduate  School 

Monterey,  CA  93943  189  copies 

Dennis  McCall 

Naval  Ocean  Systems  Center 

Code  443 

San  Diego,  CA  92152  1  copy 

Dr.  A1  Zied 

Naval  Ocean  Systems  Center 
Code  443 

San  Diego,  CA  92152  1  copy 

Dr.  Egbert  D.  Maynard 
OUSDR&E  VHSIC  Program  Office 
Room  3D-139,  400  A/N 
The  Pentagon 

Washington,  DC  20301-3000 


1  copy 


